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Another innovation from Busybox.com ©1999 


Your traditional stock search just arrived from 
(company name here). 


Here’s something to wear around the office 
as you explain why the footage sucks. 


Download this . 
~~ FeALISTOC Kom 


Introducing reelstock.com. Now you can search, preview, compare, purchase and digitally download completely royalty-free 
footage from the best cinematographers in the world. No lawyers, no licensing hassles, no surprises and no BS. You'll find 
your shots in a fraction of the time it takes to do It the old-fashioned way. So log on to reelstock.com for your next stock 
footage search. Then you can go screw-off for a couple of days and pretend you’re waiting for tapes to arrive. 


The Data Management Solution for Game Developers 











alienbrain — 


Asacomprehensive solution == =~—_—sprovides a data management 
environment that keeps track of your content from creation to delivery. 
Version control, file sharing, annotations, searching, process automation 
and status tracking are just some of the features that allow your team 
to be as productive at the size of 20 as they were with 5, and work with 





intelligence 
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Putting Curved Surfaces to Work 
on the Nintendo 64 


Feel the power of the Reality Signal Processor as 
Nintendo reveals programming techniques for 
creating Bezier curves, with the hope that upcoming 
N64 titles will have a more organic look to them. 

BY MARK A. DELOURA 


The Big Squeeze: Resource 
Management for Your Console Port 


Get tips on how to avoid memory bugs while 
efficiently managing your resources when porting 
from PC to console. Utilizing coding techniques 
such as memory pools, you can stay ahead of the 
game and reduce your game’s memory footprint. 

BY MICHAEL SALADINO 


Postmortem: Irrational Games 
SYSTEM SHOCK 2 


Using individual components from THIEF: THE DARK 
PROJECT along with the Dark Engine, the newly 
formed team at Irrational Games combined forces 
with Looking Glass Studios to create a successful 
sequel to SYSTEM SHOCK. 





BY JONATHAN CHEY 
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4 Game Plan BY ALEX DUNNE 
Graphic Content BY JEFF LANDER 
The Blobs Go Marching Two by Two 7 Bit Blasts 
— : : Criterion trots out Renderware 3, Microsoft offers a 
Artist's View BY PAUL STEED glimpse of its X-Box, and the indefatigable Jeff 
Mo-Cap and Keyframing, Sittin’ in a Tree Lander reviews Digimation’s MultiRes Software 
Toolkit and Max plug-in. 
Hard Targets BY OMID RAHMAT , 


A Tale of Two Channels 
COVER: Shodan, the cybervillain of SYSTEM SHOCK 1 and 2, 


Ss oapbox car thawen Reeve appears as a ghostly but all-too-deadly avatar in the endgame of 

A Platform foc New Ideas SS2. Illustration in pencil and watercolor by Gareth Hinds, lead 

Why We Need an Indie Label Now artist on SS2 and creator of TheComic.com; Gareth was responsi- 
: ble for redesigning Shodan and building her avatar. 
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Can Subsidized Hardware 
Save PC Gaming? 


ith one of the largest 
console launches ever 
just behind us and at 
least two more loom- 
ing on the horizon over the next 18 
months, many people are speculating 
about the features of these next sys- 
tems. Upon seeing the impressive fea- 
ture sets of the new consoles, some 
have raised questions as to the long- 
term viability of the PC as a gaming 
platform. It’s tough to look at a console 
spec sheet, read that it has broadband 
Internet access, amazing graphics and 
audio capabilities, a keyboard, DVD 
support, support for electronic software 
distribution and backwards compatibil- 
ity, and not see that the PC faces stiff 
competition. The traditional strengths 
of the PC are being co-opted by con- 
soles. I for one don’t believe PC gaming 
will go away, but the platform must 
confront these challenges head-on. 

To grow the PC market, prices must 
continue to drop. Fortunately they are, 
and it’s one reason I’m bullish on the 
PC’s future. One big reason for recent 
drops in PC prices is the direct result of 
marketing campaigns by ISPs like 
Compuserve and AOL. Compuserve, for 
example, is subsidizing the cost of 
Compaq, HP and eMachine entry-level 
systems to the tune of a $400 rebate at 
purchase. In return, these consumers 
(many of them first-time PC purchasers) 
agree to subscribe to Compuserve for 
three years at $21.95 per month. These 
ISPs are gambling that it’s better to 
underwrite the cost of these new 
machines today and recoup that invest- 
ment through extended online service 
agreements. The ISP gets reimbursed for 
its up-front investment from these 
multi-year service agreements, it gets 
“content” in the form of new chat par- 
ticipants, more eyeballs for which it can 
sell advertising space on its service, and 
other assorted benefits. If it persuades 
these indentured servants — I mean, 
customers — to stay with Compuserve 
after the agreement is terminated, so 
much the better for the ISP. The bottom 
line is that as I write this, you can buy a 
brand new 400MHz eMachine with 15- 





inch monitor and a color printer for 
about $90 more than a Dreamcast. 

While I’m glad that more PCs are 
working their way into homes — it cer- 
tainly will grow the base of casual 
gamers — there are a couple of aspects 
to these incentives that don’t bode well 
for the PC game industry. First, these 
rebate programs are seeding households 
with machines barely equipped to play 
today’s games. The latest graphics and 
audio hardware won’t be found in a 
$289 computer, and without these capa- 
bilities, the systems offer little in terms 
of a cutting-edge gaming experience. 
Second, long-term service agreements 
with online services like Compuserve 
could hamper the growth of broadband 
access to the Internet, and enabling 
broadband access is essential for grow- 
ing the online gaming market. 

It would be interesting to see a major 
game publisher like Electronic Arts step 
up and subsidize a line of high-end 
game PCs, targeting veteran PC owners 
and hard-core gamers. In return for the 
rebate at purchase, these consumers 
might agree to buy a certain number of 
games from EA over a span of years (the 
Columbia House music club model), or 
sign a multi-year subscription to a per- 
sistent game world like ULTIMA ONLINE. 
The latter option is especially intrigu- 
ing, since the risk to publishers of these 
games is high — developing and main- 
taining a persistent world is expensive, 
they are more difficult to manage, and 
more rides on their success than with 
traditional games. A publisher could 
ensure that when the game was built, 
some percentage of players would be 
locked into the game. A guaranteed rev- 
enue stream over a period of years looks 
good on the books, and in the hit-or- 
miss world of game publishing, that’s 
important to Wall Street. 

Of course, there’s nothing stopping 
any of the console manufacturers from 
launching a similar rebate program to 
entice their customers. It may simply 
be a matter of who strikes first. B 


My h2. 
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and make it perform more powerfully // 
on the latest Intel® processors 
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3ilables boolean ProcessorisGenuineIntel’s //Function: // Check for MMX(tm) Technology // (But not for Pentium*II // processor [its name 
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2>Intels fFPURCELON: a i Check For MMXCtm) Technology // (But not fo 
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//Here’s the easy way to increase your code’s power, especially if you’re pressed for time. It’s the VTune™ 
Performance Enhancement Environment 4.0. All the tools you need to take advantage of the power of the latest 
Intel processors, including the Pentium® III processor. The VTune Performance Analyzer quickly identifies performance 
bottlenecks and delivers priceless tuning advice. The high-performance Intel C/C ++ Compiler features support for 


the Pentium Ill processor's Streaming SIMD Extensions, and plugs into Microsoft Visual Studio’ And if that wasn't 





enough to whip your code into perfect shape, there's the Intel Performance Library Suite and the Intel Performance 
Training Center. Not surprisingly, this simple way to add extra muscle to your apps comes from the people who know the processor best. So 


optimize your code and make it as powerful as you imagined. < Close dialogue now > 





©1999 Intel Corporation. All rights reserved. Intel and Pentium are registered trademarks, and VTune is a trademark of Intel Corporation. 
*All other brands and trade names are the property of their respective owners. 
































| A tial | list of hit tithes built | using 
_ Beeeeon-Paradigm tools; ~*~ 


Atari Games (Midway 


San Francisco RUSH™ (N64, Arcade, PC, PC) 7. 


4 Rare Ltd. 


~ GoldenEye 007™ (N64) 


Banjo Kazooie™ (N64) 
Twelve Tales: Conker G4™ (N64) 


Zipper/EA/Hasbro 
MechWarrior lll™ (PC) 

Top Gun: Hornet’s Nest™ (PC) 
Recoil™ (PC) 


BlueShift, Inc. 
Vapor TRX rm [Arcade] Atari — 


Nintendo | “ 
, .- 


Super Mario™ (N6 
zelda™ (N64 


Origin/EA 
ae. Thay ( 2169 
Jane’s F-15™ (PC) 


Sierra On-Line, Inc. 
Viper Racing™ (PC) 

i 
SingleTrac 
Twisted Metal™* Il (PSX Pc). 
Jet Moto™* Il (PCX) , 
Outwars™' (PC] 
Streak: Hoverboard Raciflg™' (PC) 


* Trademark of Sony Computer Entertainniant ing. 
{ Trademark of GT interactive and SingleTrac 
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Contact us to request a free evaluation 
of MultiGen Creator. Visit the MultiGen- 


Paradigm web site to download the 


OpenFlight file format and get lots of 


useful realtime information 


Contact us for more detatis 


Phone: 408 261 4100 
Fax: 408 261 4103 
email: sales@multigen.com 


http://www. multigen-paradigm.com 
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¢ Import Art from 3D animation 





' tools 
- 3D Studio MAX , ’ 
- Softimage . 
- Alias | A 
- Nichimen . . . Many More 


¢ Game Data Tagging and Editing | 
* Automated Level of Detail (LOD) — 


¢ Hierarchy Structure Editing 


¢ Binary Separating Planes (BSP) 

¢ Precise UV Texture 
Mapping/Editing 

¢ Texture Rendering Control 

¢ Damage and Switch States 

¢ Degrees of Freedom (DOF) 

¢ Collision and Bounding Volumes 

¢ Instancing and External 
Referencing 


* Must be a licensed Sony or Nintendo Developer 
* Exports only Niff or HMD formats 


Images from Recoil™ courtesy 
Electronic Arts & Zipper Interactive, Inc 
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* Automated Terrain 
* Automated Roads and Pathways 


© Scene Optimization 


e..WVorld and Level Assembly 
¢ Compatable with Multiple 
Realtime Formats 
- Opentlight 
- VAML 
- NIFF 
- HMD 
* Extensibility & Customization 
- Data Read/Write API for 
converters and loaders 
_ - Data Extensions API for 
custom game data 
- Plug-in API for custom tools 
¢ Multimedia Asset Management 
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@eew Products 


by Jennifer Olsen 


A New Chip off the Old Block 


METACREATIONS has unveiled Carrara, 
its newest entry into the fray of “bar- 
gain” 3D modeling and animation 
packages. The name is appropriate 
enough: Italy’s Carrara marble has 
been prized for its unsurpassed quality 
since ancient times, back when a huge 
slab of marble was the original model- 
ing environment for 3D artists. 
Carrara is actually the marriage of 
Metacreations’ Ray Dream Studio and 
Infini-D products. So what separates it 
from the rest of increasingly crowded 
pack of 3D modeling and animation 
programs? It has much the same laun- 
dry list of features and effects as many 
of its competitors, including multiple 
renderers, Direct3D and OpenGL sup- 
port, importing and exporting of most 
industry-standard 2D and 3D file for- 
mats, scads of shaders and presets, and 
an SDK for customization. However, 
one feature that sets it apart is its clean, 
attractive user interface, which lacks 
the screen-clogging blizzard of buttons 


Carrara’s modeling interface: its lack of clutter may 
be inviting to some, limiting to others. 
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characteristic of certain wildly popular 
high-end packages. 

Carrara will sell for $499 and run on 
Windows 95/98/2000/NT 4.0 and 
Macintosh platforms. 

M@ Metacreations Corp. 

Carpinteria, Calif. 

(805) 566-6200 

http: //www.metacreations.com 


X-File Management and More 


NxN SOFTWARE has announced Alien- 
brain, the successor to its groundbreak- 
ing asset management tool tailored 
specifically for game developers, 
MediaStation. Remember back in high 
school when you wrote your first game? 
Maybe you had a few dozen files and 
kept track of them on the back of your 
physics homework. Whatever system 
you had, it wouldn't work on today’s 
development projects which now com- 
prise thousands of files and mountains 
of media to manage. 

The folks at NxN feel your pain, and 
Alienbrain is their antidote to the 
mind-boggling complexity of manag- 
ing a game development project. The 
client/server system includes four mod- 
ules to track file management, version 
control, process automation and pro- 
ject tracking across differ- 
ent user groups: “Genius” 
is designed for the artists 
on your team, “Intelli- 
gence” for the program- 
mers, “Control” is the 
command center for pro- 
ject administrators and 
tool developers, and 
“Knowledge” is for pro- 
ducer-types. While the 
nomenclature won’t settle 
any debates about who 
the real brains on your 
team are, each module 
contains features and 
functionality unique to 
the needs of its users. 
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New Products: Metacreations intro- 
duces Carrara, NXxN rolls out Alien- 
brain, and Criterion unveils its next 
generation of Renderware. p.7 


Aureal busts out with boards. p. 8 


Product Review: Jeff Lander sings the 
praises of multi-resolution meshes as he 
reports on Digimation’s MultiRes Toolkit 
and Plug-in for 3D Studio Max. p. 10 


Industry Watch: Dell snubs ATI, 
Microsoft shows off its new console, 
Sony divulges more PSX2 secrets, and 


Alienbrain’s server systems require 
Windows NT 4.0 or later, and clients 
require Windows 95/98/2000/NT 4.0. 
Pricing was not yet finalized at press 
time, but the servers are expected to 
cost in the neighborhood of $4,900, 
with client systems priced at around 
$1,900. NxN also offers flexible volume 
pricing packages. 

M@ NxN Software AG 

Munich, Germany 

+49 (89) 27-32-24-0 

http://www.alienbrain.com 


Gearing Up for the Next Generation 


CRITERION SOFTWARE has revealed the 
third generation of its multi-platform 
3D development toolkit, Renderware. 
By now we’ve all gotten an idea of 
what the near future of 3D gaming 
holds both for PCs and consoles. As 
demands on developers increase, plat- 
forms diversify and pressure builds to 
decrease development lead time, more 
developers may be considering outside 
resources for help. 

Renderware is based on a streamlined 
plug-in architecture that allows develop- 
ers to mix and match functionality by 
overloading the pipeline with their own 
tools (physics or collision detection, for 
example,) when they so desire. The PC 
version supports Glide, OpenGL and 
Direct3D, with a device-independent 
architecture that will enable easier port- 
ing to consoles and tomorrow’s digital 
TV platforms. 

Renderware 3 will be available by 
year’s end for PC, Playstation 2 and 
iMac at $1,000 per programmer per 
platform per year with no royalties, 
and third-party plug-in development is 
in full swing. Linux, Dreamcast and 
Nintendo Dolphin versions of Render- 
ware are also being considered. 

M@ Criterion Software Ltd. 

Guildford, Surrey, U.K. 

+44 (0) 1483-406200 

http: //www.renderware.com 
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a Industry Watch 


by Alex Dunne 


DREAMS DO COME TRUE. Sega’s Dream- 
cast launch proved to be better than 
the company hoped, with preliminary 
figures indicating that $97 million in 
sales were rung up around the U.S. on 
9/9/99. Sega claims it was the biggest 
24 hours in entertainment retail sales, 
easily surpassing the $28 million that 
The Phantom Menace took in on open- 
ing day last May. 


PSX2 NEWS. Carefully timed to coin- 
cide with the Dreamcast launch, Sony 
stole some of Sega’s thunder with a 
number of Playstation 2 announce- 
ments. The company revealed that the 
PSX2 will debut in Japan next March 
(three months later than originally 
planned, possibly due to chip manufac- 
turing problems), and in the U.S. and 
Europe next fall. Japanese consumers 
will have to cough up 39,800 yen ($365 
at press time) for the system. Sony also 
revealed that it will distribute games via 
the Internet, made possible by the 
PSX2’s broadband support and an 
upcoming hard drive Sony will sell. To 
support this new means of distributing 
console titles, Sony is creating an elec- 
tronic transaction system, and an e- 
distribution server. In developer news, 
Sony will give PSX2 developers tools 
that support the regular Playstation 
programming/debugging mode as well 
as a new workstation mode for creating 
PSX2 graphics, all on the same system. 


ENTER MICROSOFT... At ECTS, Micro- 
soft demo’d its upcoming console 
(code-named the “X-Box”) to various 
developers and analysts. As we go to 
press, no release date for this console 


Sony took advantage of the Dreamcast launch 
to divulge more tidbits about the Playstation 2. 
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has been hinted at, and product specs 
are sketchy. But the word on the street 
is that the X-Box will be based around 
a SOOMHz Intel chip, the Nvidia 
GeForce 256, a DVD drive, a multi-giga- 
byte hard disk, and of course, some fla- 
vor of Windows. Who will produce this 
console? Not Microsoft, apparently — 
Dell, Gateway and Samsung have been 
lined up as manufacturers. 


IT’S TEN NO MORE. Total Entertainment 
Network (TEN) ditched its name and its 
target market, deciding that the casual 
game market is more lucrative than its 
previous focus on hard-core players. The 
company, now called Pogo.com, is 
focused strictly on card, trivia, board 
and other “family” games. The site has 
more than 3.5 million members, and 
has lined up has distribution relation- 
ships with @Home, Alta Vista, Cnet, 
Excite, Go, Netscape, and Sony. 


BE LINES UP TITLES. Be Inc. and Mono- 
lith announced that SHOGO: MOBILE 
ARMOR DIVISION will be brought to the 
BeOS. SHOGO will be developed and pub- 
lished for BeOS by Wildcard Design. At 
ECTS, Be showed CIVILIZATION: CALL TO 
POWER, CORUM 3, and QUAKE 2 running 
on its operating system. 


DELL DECISION HURTS ATI. ATI 
acknowledged that Dell’s recent deci- 
sion go with Nvidia chips in its 
OptiPlex computer line will cost ATI 
$10 million in sales per quarter. The 
company still expects to meet fourth- 
quarter sales projections when it 
reports results on October 21, but that 
didn’t quell some panicked investors, 
and trading of ATI’s stock was halted 
on both the Toronto and Nasdaq 
exchanges after the company revealed 
the cost of that lost deal. ATI points 
out that it will still supply Dell’s note- 
book PCs, and that its relation- 
ship with the big computer 
company is still strong. 


AUREAL LAUNCHES CARDS. 
Aureal entered the board busi- 
ness and is shipping two new 
Aureal-branded sound cards, 
the Vortex $Q1500 and the 
Vortex2 $Q2500. The new 
cards are marketed under the 
Aureal name by I/OMagic 
Corporation, and are support- 
ed by a multimillion dollar 
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marketing campaign. Based on 
Aureal’s AU8810 processor, the 
SQ1500 supports A3D 1.0 and features 
a 512-voice wavetable synthesizer. The 
SQ2500 is based on a new version of 
the Vortex2 AU8830 processor and 
supports A3D 2.0 with a 576-voice 
wavetable synthesizer. 


1999 60 RoadTrip 


OGDEN | ECCLES CONFERENCE 

CENTER = 
Salt Lake City, Utah = 
November 1, 1999 


THOMPSON CONFERENCE CENTER 
AT THE UNIVERSITY OF TEXAS 
Austin, Tex. 
November 3, 1999 


Cost: $120 ea. (discounts available) 
http://roadtrips.gdconf.com 


Software Development East 


WASHINGTON CONVENTION CENTER 
Washington, D.C. 
November 8-12, 1999 
Cost: variable 
http://www.sdexpo.com 


RE:Play Real World Conference 


TISCHMAN AUDITORIUM AT THE 
PARSONS SCHOOL OF DESIGN 

New York, N.Y. 

November 13, 1999 

Cost: free 

http: [Ww w.eyebeam.org/replay 


Comdex Fall 


SANDS EXPO & CONVENTION CENTER 
Las Vegas, Nev. 
November 15-19, 1999 
Cost: variable 
http://www.comdex.com 
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calable 3D graphics has been a 
major event in 3D graphics this 
past year. With so many differ- 
ent gaming platforms and such a variety 
of graphics cards, making content that 
performs similarly on all systems is a 
real challenge. Game developers have 
commonly used different level-of-detail 
models to balance the performance. 
However, creating LOD models is a time 
consuming and tedious project for any 
game artist. Furthermore, dynamically 
changing between LOD models during 
the game can lead to annoying popping 
as they switch. Graphics researchers 
have been promoting the idea of con- 
tinuous LOD algorithms for 3D models. 
In these algorithms, the model will 
smoothly scale from very high to very 
low polygon counts. In fact, Stan Melax 
wrote an article in this magazine about 
implementing a continuous LOD sys- 
tem (“A Simple, Fast, and Effective 
Polygon Reduction Algorithm,” Novem- 
ber 1998). However, creating a system 
that handles all the lighting and texture 
information and smoothly integrates 
into your production is a task that 
could easily tie up development 
resources for some time. 





| DON’T HAVE THAT KIND OF TIME. With 
this in mind, I looked with interest at 
several commercially available continu- 
ous LOD systems at Siggraph 1998. 
One of these was a very interesting sys- 
tem developed by Intel. At the time, 
the project was not quite ready to be a 
product, but looked very promising. 
Well, at the GDC this year, Intel 
unveiled the fruits of this labor. They 
have teamed up with Digimation to 
produce the MultiRes Software Toolkit 
and Plug-in for 3D Studio Max. 

The MultiRes Plug-in enhances 3D 
Studio Max by providing a method for 
reducing a high polygon mesh to a 
lower polygon count mesh. In this way, 
the plug-in is similar to the Optimize 
routine that is built into 3D Studio 
Max. However, MultiRes is quite a bit 
more powerful. For example, you can 
set exact polygon count targets as well 
as a reduction percentage. Also, Mullti- 
Res does an excellent job of preserving 
texture coordinates and vertex normals. 
Artists are even able to fine-tune the 
reduction algorithm by a variety of con- 
trols as well as selecting the vertices not 
to remove. 

As a modeling tool alone, this pro- 
vides a pretty powerful and useful way 
for artists to craft content. However, the 
real power of MultiRes is realized by 
creating a multi-resolution mesh. This 
special mesh file contains all the infor- 


| . The bottom dinosaur’s 
face count has been reduced dramati- 
cally, but looks fine from a distance. 





Jeff Lander is always trying to find a tool to make his life easier and cut down on 
unnecessary work at Darwin 3D. If you can recommend any nifty tools, pass them 


on to jeffl@darwin3d.com. 
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mation needed to create a mesh that 
can dynamically scale from its full reso- 
lution down to 1 polygon composed of 
3 vertices. This MultiRes mesh can then 
be used directly in your game as scal- 
able content. It can also be exported 
into the MetaStream 3D format that is 
used with tools from MetaCreations to 
view scalable 3D models on the web. 

You can see an example of MRM in 
action in Figure 1. The first image is the 
original mesh at 6,126 vertices or 
11,766 faces. I then reduced this down 
to just 64 vertices for 120 faces. Obvi- 
ously, this looks pretty bad up close, but 
when the object gets far away it looks 
fine. The MRM algorithm preserved the 
outline of the arms and legs. This is 
where real-time use of MultiRes really 
makes a difference. A herd of these ani- 
mals at full resolution would grind any 
system to a halt. But a herd of them at 
120 polygons is perfectly reasonable. 
HOW DOI USE IT? If you are a 3D Studio 
Max user, the plug-in couldn’t be any 
easier. You simply select your model 
and select the plug-in from the Modifi- 
er panel. You can then “Generate” the 
MultiRes mesh and start interactively 
reducing the vertex count in the 
model. The default generation options 
do a good job of mesh reduction for 
many models. However, you can really 
fine-tune the operation. 

The “Vertex Merging” option allows 
you to determine whether or not 
unconnected areas of the mesh will be 
merged as the reduction proceeds. You 
specify the maximum distance in 3DS 
Max units that the algorithm will con- 
sider for merging. This can be useful if 
your mesh is composed of parts that 
are not topologically connected. 

“Boundary Metric” gives you the 
options with respect to any material 
changes in to model. It will then try to 
avoid collapsing vertices that cross 
these material boundaries. 

Most of the time, the algorithm 
along with these options will allow 
you to create a good mesh. However, 
there are times that you will want to 
select vertices that you do not want to 
collapse in the model. Perhaps there is 
a feature in the model that is distinct 
and you wish to be preserved. You can 
select the “Maintain Base Vertices” 
option and then select the vertices you 
wish to preserve. These vertices will 
then be maintained throughout the 
reduction process. 
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The final option determines how the 
normals in the model will be handled. 
While vertices are removed, the topolo- 
gy can change pretty dramatically. You 
can simply use the original vertex nor- 
mals throughout the reduction. Other- 
wise, by setting the “Multiple Normals 
per vertex” option, the system will cre- 
ate new normals based on the surround- 
ing faces as the model reduces. This 
option comes at the cost of increasing 
the number of update records that must 
be recorded. Whether or not this is 
needed depends greatly on your applica- 
tion and models. 

That’s all there is to it. Once you are 
happy with the reduction, you can save 
it out, ready to use in your application. 
BUT | DON’T USE MAX. If you don’t use 
3D Studio Max, you won't get the bene- 
fit of this nifty plug-in. However, the 
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FIGURE 2. The MultiRes user 
interface. 
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benefits of MultiRes are still available to 
you. The MultiRes Software toolkit con- 
tains all the functions you will need to 
create a scalable mesh. You simply set 
the parameters for the reduction and 
submit a structure containing all the 
vertices, normals, and faces in the 
model to the GenerateMRM function. 

I found it very easy to take models 
created in Softimage and convert them 
into a MRM by modifying the Digima- 
tion sample viewer. This would be easy 
to do for any polygonal model. 

SO HOW DOI USE IT IN MY GAME? Now I 
have a nice MRM all ready to go and | 
want to use it in my game application. 
The examples provided with the 
Software Toolkit make this easy. There 
is both a Direct3D and OpenGL exam- 
ple of working with a MultiRes mesh. 

One thing developers will appreciate 
is that while the MRM generation func- 
tions are in a Dynamic Link Library 
(DLL), all the run-time code needed to 
display and manipulate the meshes are 
straight C. You need no extra libraries 
to ship with your project. This also 
makes it possible to use the MRM tech- 
nology on game consoles. 

Also, as the algorithm works by 
changing the connectivity of the 
meshes, the actual vertices are left 
alone. This means that the MultiRes 
algorithm can work with most anima- 
tion schemes such as skeletal deforma- 
tion, morphing, or even QUAKE-style 
mesh flipping. 

OTHER FEATURES. The MultiRes Toolkit 


also offers another very valuable feature. 


In order to render polygonal meshes in 
the fastest way possible, many 3D 
graphics cards prefer to receive the 


MultiRes: 


Digimation Inc. 
St. Rose, La. 
(800) 854-4496 
http://www.digimation 
.com 


| 
Price: Plug-in is $295. 
Software toolkit is | 
$5,995 per finished | 
game, including three 
copies of the plug-in. | 
Software Requirements: 
Windows 95/98/2000/ 
NT 4.0; 3D Studio Max : 
for the plug-in. 
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_ 4. Full source code for plug- 
in and run-time modules 
for Direct 3D and 

OpenGL. 


_ 2. High-quality polygon- 


reduction algorithm with 
great performance. 

_ 3. No per-copy royalties on 
game Sales. 


meshes as triangle strips. These strips 
can be tricky to create and often require 
custom tools to generate them. 

MultiRes provides a way to generate 
triangle strips from a polygonal model. 
However, since the model’s topology 
changes, as the level of detail changes 
an initial triangle strip would become 
invalid. To address this issue, the Multi- 
Res Toolkit provides a way to generate 
triangle strips on the fly. Very cool... 
WHAT’S THE BOTTOM LINE? The 3DS Max 
MultiRes plug-in is $295. By itself, this 
plug-in may be of use to Max modelers 
who wish to have a better polygon 
reduction tool or want to generate 
MetaStream objects for web viewing. If 
you don’t use Max or really want the 
game interactivity, this is probably not 
for you. 

The MultiRes Software Toolkit 
includes three license copies of the Max 
plug-in as well as all the libraries and 
code needed to generate and display 
continuous LOD meshes. The cost of 
the toolkit is a flat fee of $5,995 per fin- 
ished game title. When you consider all 
the technology included and the 
amount of development time it would 
take to create this functionality, this 
seems like a great deal to me. 

Obviously, I’m not the only one who 
thinks this is interesting. Both Valve 
with TEAM Fortress 2 and Pandemic 
Studios with DARK REIGN 2 have licensed 
the MultiRes Toolkit for their upcoming 
3D titles. | expect many more to follow. 

MultiRes is the first commercial pro- 
ject to come out of the collaboration 
between Intel and Digimation. I cer- 
tainly look forward to other products 
that come of this partnership. & 


- Cons: 


| 1. Plug-in only comes for 
3D Studio Max. Users of 
other packages must roll 
their own conversion 
programs from library 
included in SDK. 


. Toolkit cost is up-front 
although pretty reason- 
able. 


. Users will need to adapt 
their game engines to 
work with the multi- 
resolution meshes. 
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by Jeff Lander 





The Blobs Go Marching 


Two by Two 





In fact, many of these objects are not 
even just lying around looking all 
organic. They slop, splash, waddle, and 
plop about you all the time. Many 
shapes around you are even in motion. 
These objects change shape effortlessly 
as you game artists crumple under the 
pressure of having to model such phe- 
nomena. When was the last time you 
saw a nice splashing fountain in a 
game, anyway? 

Animators have faced the challenge 
of visually creating the organic world 
we live in for some time now. To help 
them out, commercial modeling pack- 
ages have provided the artist with tools 
for creating organic shapes. One of the 
methods for creating organic objects is 
through the use of blobby balls that 
can be combined together to form a 
clay-like sculpture. The commercial 
animation package developers have 
realized the usefulness of this tech- 
nique and coined all sorts of propri- 
etary terms for their version. You may 
have seen ads for meta-balls, meta-clay, 
blob-modeling, and various other ways 
of combining the term “meta” with 
some form of goop. 

To create an object from this meta- 
goop, an artist drags around primitive 
elements, usually spheres, which repre- 
sent the rough shape of the object. 
Each of these elements has a center 
position and several parameters associ- 
ated with it. These parameters define 
how the element will interact with the 
particles and world surrounding it. You 
can see an example structure for a 
meta-goop particle in Listing 1. 

The position describes the center of 
the element. I also need to keep track 
of the radius of influence of the ele- 
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ment (actually squared so I save some 
math later) and the strength of the ele- 
ment. This strength parameter defines 
how the element will affect the space 
surrounding it. 

The elements interact with each 
other by creating an energy field 
around them. This is similar to the 
way planets create a gravitational field 
for a solar system. It is possible to eval- 
uate the energy of the system at an 
arbitrary point in space. The formula 
to determine the amount of energy 
that an element contributes to the 
point is given as: 
distance = squaredDistance(&goop-> 

position, &testPosition) ; 
if (distance < goop->radiusSquared) 
{ 
falloff = 1.0f - (distance/goop-> 
radiusSquared) ; 
fieldStrength += goop->strength * falloff 
* falloff; 


By running this formula over all the 
elements in your system, you get the 
exact field strength for that position. 
The energy field creates some interest- 







G 1. A meta-goop particle. 


typedel tMetaGoop 
{ 


tVector position; 
float radiusSquared; 
float strength; 


}; 
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When not splashing gloop around his kitchen floor, Jeff can be found creating real- 
time graphics applications at Darwin 3D. Fling some bits of your own his way at 


his may come as a shock to some, but the world is not made up of corridors 
composed of completely planar surfaces. We live in a wildly organic place. 
Hills roll, muscles bulge and fountains splash. The world around you is 


filled with organic shapes which cannot easily be created out of triangles. 


ing data but is not much of an object. 
What I want to create are particles that 
will visually grow together as they get 
closer. You can see an example in 
Figure 1. In order to create an object 
that will show this visual aspect of the 
energy field, it is necessary to define a 
value that will represent the outer shell 
of the object — the threshold. 

The energy field varies in strength 
from zero on up at any position you 
may evaluate. In fact, there is nothing 
to keep you from defining negative 
strength for an element, creating nega- 
tive regions, or holes, in the energy 
field. This is useful for effects such as 
denting and the like. To define the sur- 
face of the object in the field, I can set 
an arbitrary threshold giving the object 
its final shape. 

The threshold value defines the 
boundary between the area inside and 


The “meta-goop" seen here produces 
results that are difficult to create with 
traditional modeling techniques. 
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FIGURE 1. Our goal is to make our three particles visually grow together as they get closer to one another. 


the area outside the shell of the object. 
Figure 2 shows how an example thresh- 
old value creates a boundary in a 2D 
energy field created by three meta-goop 
entities. 

By adjusting this threshold value for 
the energy field, as well as adjusting 
the strength, position, and effective 
radius of individual entities, a great 
variety of objects can be created. But | 
still need to talk about how. 


Walking on Eggshells 


ef y creating a few meta-goop parti- 
cles and setting some values for 
them, I have created my meta-goop 
system. Run that goop through a func- 
tion that evaluates the energy field, 
apply a surface threshold, and I have 
the surface shell for the meta-goop 
object defined. But the problem 
remains, how do I draw it? 








I could step across the entire 3D 
space defined by entity radii and eval- 
uate the field. Anywhere the returned 
value is equal to the threshold, I could 
draw a solid cube the size of the steps 
taken. This sounds pretty good. 
Sounds like it would work. Actually, it 
sounds kind of familiar. It sounds 
kind of like volume rendering of vox- 
els for applications such as viewing 
CAT scan data. In fact, that is exactly 


Announcing the new standard in automatic 
character mouth synchronization. 


Down- 





Load 
Now! 
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PC requirements: OS Win 98/NT 4.0+ ¢ 3D Studio Max r3.0+ 





what I would be doing if I took this 
approach. 

However, rendering the energy field 
this way can lead to pretty chunky look- 
ing images unless the step size is fairly 
small. This is because the energy field is 
continuous over the entire range of the 
model world. However, the steps I took 
walking across the field are in discrete 
steps. If the steps are too big, the image 
can look chunky. This is analogous to 
drawing a line on a computer graphics 
screen. If the resolution of the screen is 
too low, the line can look very jagged. 
This unfortunate condition is known as 
“the jaggies” and requires some form of 
smoothing or antialiasing to make the 
lines look better. 

Unfortunately, decreasing the step 
size in my energy field will greatly 
increase the amount of calculations 
that must be made. Therefore, it is nec- 
essary to find a way to smooth out the 
voxel image — sort of antialias the 
meta-surface. 


CAT Scans and Game Development 


ones for me, the graphic 
visualization and medical imaging 
industries have been dealing with this 
issue for quite some time. Wyvill and 
McPheeters in 1986 and Lorenson and 
Cline in 1987 independently devel- 
oped a system called “marching 
cubes” which enables you to render a 


polygonal approximation of a voxel 
field. One possible unfortunate cir- 
cumstance is that this algorithm may 
be tainted by a software patent and I 
am investigating how this will affect 


The Marching Cubes Patent Question 


Ss many of you who have met 
me and heard me rant on 
the topic know, | believe 
algorithmic software 
patents are totally wrong. | feel they 
completely halt continued development 
down interesting research pathways by 
shrouding a topic with legal pitfalls. 
Graphics researchers create progress by 
building on the work done by others 
before them. | like to imagine the state of 
the industry if Bresenham had patented 
his method for drawing a line on a graph- 
ic display and then charged a licensing 
fee for every line drawn. 

The topic of volume rendering is an 
interesting case in point. As an obvious 
next step in the visualization of volume 
data, it was reported by researchers in 
several publications. However, General 
Electric apparently owns a patent on the 
technique via the Lorenson and Cline 
implementation (U.S. patent 
#4,710,876). As an actual apparatus to 
display medical imaging data, | can 
understand it. However, the patenting of 
a “method for displaying three-dimen- 





sional surface images” seems pretty 
broad to me. 

| have been told by someone via e-mail 
that GE aggressively enforces this patent. 
However, it is not clear to me how this 
would apply to the rendering of an isosur- 
face in a game. Does this mean that any 
modeling program using these tech- 
niques must pay a license to GE? If I cre- 
ate a game using a derivative of marching 
cubes and it is a big hit, am | going to 
receive a stealth patent letter in the mail 
demanding a percentage? How derivative 
does it need to be? The prior art on this 
topic seems limitless, but what can | use 
as a reference and still be safe? 

With the record number of software 
patents being filed, this is going to 
become an increasingly difficult issue for 
game developers in the future. | am 
actively researching the issue and hope 
to report on the results in a later column. 
Anyone with information on the topic, 
please let me know. In the meantime, 
always document your research from 
public journals as best you can. Igno- 
rance is not bliss in this situation. 
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the issue (see Sidebar). 

That aside, the way marching cubes 
works is pretty simple. Divide the 
region you wish to render into a regu- 
lar 3D grid. Evaluate the energy field at 
each position on this grid. Now, con- 
sider the grid cube by cube. If the ener- 
gy function at all eight corners of the 
cube are less than the threshold level, 
the entire cube is outside the meta- 


{ 


tVector diff; 
float ratio; 


VectorSubtract( a, b, &diff); 


if (aVal > bVal) 


FIGURE 2. Creating a boundary threshold ina } 


2D energy field. 
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void FindIntersection( tVector *a, tVector *b, 
float aVal, float bVal, 
float thresh, tVector tresult) 


object and the cube can be ignored 
completely. Likewise, if the corners are 
all greater than the threshold, the cube 
is completely inside the object and can 
also be ignored. The only cubes that 
need further consideration are those 
that have corners both inside and out- 
side the meta-object. These cubes are 
on the object surface and will be part 
of the final render. 


LISTING 2. Finding the intersection point. 







/// Local Variables LLL 


INTACT 


ratio = (thresh - aVal) / (bVal - aVal); 
VectorMultiply( &diff, ratio); 
VectorSubtract(a, &diff, result) ; 
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FIGURE 3A. One vertex inside and 
the rest outside create one triangle. 


A cube has eight vertices. That 
means that there are 256 possible com- 
binations of how a surface can intersect 
with the cube. If you consider symme- 
try, the number of possibilities reduces 
to 14. Much of the literature on surface 
generation using the marching cubes 
routine deals with optimizing for those 
14 special cases. 

However, there is an easier way | 
have seen termed “marching pyramid.” 
If you consider a cube of eight vertices 
as being composed of five tetrahedrons 
with four vertices each, the problem is 
greatly simplified. There are now only 
three very simple cases to deal with. 
The cases are the following: 

1, One vertex is inside the surface 

and the rest outside. 

2. One vertex outside the surface 

and the rest inside. 

3. [wo vertices outside and two 

inside. 

That is all I need to consider. In cases 
1 and 2, a single triangle is generated. 
In case 3, two triangles are generated. 
You can see the three cases represented 
in Figures 3a-—c. 

Once the vertices of the pyramid are 
Classified, the actual vertex positions 
of the triangles created are obtained 
by linear interpolation of the corner 
values along each edge. You can see 
the code for this in Listing 2. As there 
are five tetrahedrons making up each 
cube, the number of triangles generat- 
ed with the marching pyramid tech- 
nique is greater than what would be 
created from simple marching cubes. 
However, the classification and cre- 
ation step is much simpler and the 
resultant surface is a more accurate 
approximation of the surface. On cur- 
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FIGURE 3B. One vertex outside and 
the rest inside also make one triangle. 





rent 3D graphics hardware, the extra 
triangles shouldn’t affect performance 
too much. 


Goopy Games 


hope it is now clear that these meta- 

goop techniques can be used to cre- 
ate interesting organic objects suitable 
for real-time display. However, there 
are several aspects that actually make 
them ideal for use in games. For one, 
they are procedurally created. Complex 
structures can be generated from sim- 
ple data structures consisting of the 
location and attributes of each particle 
in the system. There is no need to store 
a complete mesh. 

In addition, the meta-object can be 
tessellated to different levels depend- 
ing on the initial grid size of the voxel 
space. This gives the game a dynamic 
level-of-detail component that is 
needed in these days of varying hard- 
ware performance. 

You can attempt generation of the 
objects in real time through efficient 
optimization of the surface approxima- 
tion routine. You could also simply 
decide to create the objects at load time 
and display them as traditional polygo- 
nal objects during the actual game, or 
evaluate the mesh only when the state 
of the goop elements changes. This 
kind of flexibility makes for easy inte- 
gration into a variety of applications. 

I didn’t even discuss how the sur- 
faces could be rendered. One obvious 
choice would be to apply environ- 
ment-mapping techniques to create 
the chrome creature from Terminator 2. 
Likewise, you could apply bump-map- 


Lgs9 





FIGURE 3C. Two vertices outside 
and two inside create two tringles. 


ping techniques to bring a water crea- 
ture to life. | think an interesting 
application would be to combine 
meta-surface techniques to a particle 
system like the one I described last 
summer (“Spray in Your Face,” 
Graphic Content, July 1998). 

For more fun, get my demo applica- 
tion off the Game Developer web site 
(http://www.gdmag.com), This will 
allow you to play with the creation of 
meta-goop and start spreading some 
slop around your games. @ 


¢ Greene, Ned. “Voxel Space Automata: 
Modeling with Stochastic Growth Pro- 
cesses in Voxel Space (Proceedings of 
Siggraph 89).” Computer Graphics, 
Vol. 23, No. 4 (Aug. 1989): pp. 175-184. 

¢ Lorensen, William, and Harvey Cline. 
“Marching Cubes: A High Resolution 
3D Surface Construction Algorithm 
(Proceedings of Siggraph 87).” Com- 
puter Graphics Vol. 21, No. 4 (Aug. 
1987): pp. 163-169. 

e Watt, Alan, and Mark Watt. Advanced 
Animation and Rendering Techniques. 
Reading, Mass: Addison-Wesley, 1993. 


e Wyvill, Geoff, Craig McPheeters, and 
Brian Wyvill. “Data Structure for Soft 
Objects.” The Visual Computer Vol. 2, 


No. 4 (Aug. 1986): pp. 227-234. 


Web Resources 

e http://www.students.cs.ruu.nl/ 
people/jedik/Methods/ 
Surface_fitting/Marching cubes.htm 


e http://www.swin.edu.au/astronomy/ 
pbourke/ modelling 
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The Power Mac G4 is here. 





Computers get marginally faster every year. 


Megahertz, a popular (but simplistic) measure 


deigs 


of performance, usually increases around 35% 

annually, But once or twice in a decade, we 

experience a breakthrough that leaps far beyond 

these incremental steps. Today we present such 

a breakthrough: the new Power Mac’ G4. 
This is not just the fastest Mac’ in history. 

It’s the fastest personal computer in history. 
Rather than being just 35% faster, the new 


Power Mac G4 is up to a stunning 100% to 200% 


faster than the fastest Pentium I1I-based PCs: 





With performance increasing at its usual pace, 
the new Power Mac G4 wouldn't have arrived until 


2003. Fortunately, breakthroughs do happen. 
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What you really need is a supercomputer. 


Supercomputers have helped achieve breakthroughs 
in almost every field of science. But almost no one 
outside the scientific community could possibly need 
one. Or so it was thought. 

That was before Photoshop filters started resembling 
the most sophisticated image processing done by 
NASA. And before Internet security started demanding 
CIA-strength cryptography. And before compressing 
QuickTime or MP3 files started expanding your workday 

These tasks, and many more like them, have two 
things in common: They choke traditional processors. 
And they can be dramatically sped up by exactly the 
kind of computational horsepower that supercomputers 
were created to provide. 

But who has the money, or even the space, to have 


their very own supercomputer? 
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A revolutionary computer 


dleserves a revolutionary display. 


Introducing the ultimate companion to the Power 
Mac G4: the Apple Cinema Display.’ With its 22-inch 
screen (measured diagonally), it’s the largest LCD 
display ever brought to market. 

Its viewable area is as big as a 24-inch flat CRT 
display, But it’s twice as bright and sharp, with triple 
the contrast ratio and zero flicker. And its millions of 
colors remain true from almost any viewing angle. 

Like a movie theater, the Apple Cinema Display has 
a letterbox format (1600x1024 pixels), with room 
enough to display an entire 11x17 image. And unlike 
most other displays, it receives its data digitally trom 
the computer, preserving the highest-quality image. 


The Apple Cinema Display is state-of-the-art 


technology, and supplies will be limited. And at $3999 


it’s not for every pocketbook. But if you're fortunate 
enough to use one, your office view will never be the 


Same again. 


*Sugvested retail price 


If you dontt see your pertect G4 here, 


feel free to build your own. 





Price’ $1599 $1999 


$2799 


$3499 
































Processor 400MHz G4 450MHz G4 450MHz G4 SOOMHz G4 
L2 Backside Cache LMb IMB IMB IMB 
QO0OMH= 225MHz 225MHz 250MH= 
Memory (SDRAM) 64MB 64B L28MB 128MB 
1.0GB max. 1.0GB max. 15GB max. 15GB max. 
Max. Memory Bandwidth 400MB/sec 400 MB/sec SOOMB/sec SOOMB/Sec 
Graphics RAGE 128/PCI RAGE 125/PCI RAGE 128/AGP 2X RAGE 125/AGP 2X 
16MB graphics memory LOMB graphics memory LOMB graphics memory /6MB graphics memory 
Hard Drive 10GB 13GB 20GB 27GB 
3 internal bays, 1 used Ultra ALV33 Ultra AIV33 Liltra ATV66 (tra ALV66 
Removable Storage CD-ROM DVD-ROM DVD-ROM DVD-RAM 


DVD-Video playback 
/0OMB Zip Drive 


DVD-Video playback 
LOOMB Zip Drive 




















DVD-Video playback 





Ethernet 10/ 1OOBASE-T yes yes yes yes 

FireWire Ports ( 400Mbps) Z 2 3 (1 internal) 3 (1 internal) 
USB Ports 2 (12Mbps total) 2 (12Mbps total) 2 (24 Mbps total) 2 (24Mbps total) 
AirPort™ Wireless Networking n/a 1/d Optional Optional 
/1Mbps IEEE 802.11 

50K V.90 Modem Built in Built in Optional Optional 
Apple Cinema Display n/a n/a Optional Optional 





Find the new Power Mac G4 at your local authorized Apple reseller. Or build your own perfect system— 
from over 15,000 configurations —by visiting the Apple Store* at www.apple.com. 
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Apple Store, Power Mac. 
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~ Visual (++ Developers: — 
oo. Expand what you already know and 
ie. shorten your 3) development cycle. — 


With 3DLinX™, you can open a whole new world using universa 
COM/DCOM and ActiveX® standards. In minutes you can create 
tunning 3D simulations, applications and web pages using | 


al C+ +© and Visual Basic®. oo 


‘SDLinx is the world's first language-independent, fully integrated 
visual 3D development environment for real-time rendering. 


‘Creation using 3DLinX at run-time with the power of OpenGL 3 
shortens your 3D development cycle. 


st add 3DLinX. 





* 
* 





ee SS ee) ee es | | — 2 
| : Visit www.3DLinX.com or call 1-877-3D MAJIC for an evaluation copy. : 
__ Be sure to check out the Visual Basic 3D contest for a chance fo win up to $4,000 in prizes! 
| Revolutionary Tools for 3D Software Development ae : 


2 








by Paul Steed 





Mo-Cap and Keyframing, 


Sittin’ in a Tree 





debate when it comes to character ani- 
mation: keyframing vs. motion capture. 

Analogous to the classic Luddite/ 
Promethean struggle that occurs still in 
the scientific community, animators 
tend to divide themselves into two 
camps. On one side you have the purists 
who believe mo-cap is the evil product 
of technology run by marketing blow- 
hards. On the other you have the strate- 
gist artist who is constantly looking for 
the better, faster way to get the job 
done. Because in the end if your artwork 
is featured in a computer game and not 
a gallery in New York City, it boils down 
simply to getting the job done. 

Mo-cap can and will help get the job 


FIGURE 1. Q3A’s Orbb marches to 
the beat of a different drummer. 


done faster and better. Like any other 
tool available to the computer artist/ani- 
mator today, it can be used in various 
ways to various degrees. What I’m going 
to do is demonstrate a situation in 
which motion capture and keyframing 
can be married — no, have to be married 
together — to form a solution for one 
instance of character animation. 


I've Got My Eye on You 


el eet Orbb. He’s cool. He’s a charac- 
ter we created for QUAKE 3: ARENA 
(with textures by Kenneth Scott) solely 
for the weirdness of making him run 


FIGURE 2. An orthographic view of Orbb’s pecu- 


liar anatomy. 





San artist, you’ve heard at one time or another some pretty common 
arguments: photo reference vs. “from memory,” tracing vs. hand- 
drawing, or scanned images vs. hand-painted ones done in Photoshop. 


However, for animators working on computer games today, there’s a new 


around on his hands (Figure 1). Because 
of the animation system of the game, 
affording or even showing off any type 
of complex finger animations is impos- 
sible. However, using a little bit of prob- 
lem solving Orbb becomes a great exper- 
iment in evenly combining motion 
capture and keyframed animation. 

I’ll explain. Figure 2 shows amore 
orthographic view of our ocular, podi- 
atrically-challenged little friend. In the 
Q3A game engine, each character must 
be divided into three distinct parts: 
head, torso and legs. The parts are tied 
together using a simple triangle tag sys- 
tem (match tab a to tab b). The head 
and torso basically move around when 
you move your mouse 
around (free look) with the 
head motions slightly lead- 
ing those of the torso. The 
legs are purely locomotive 
and couldn’t care less what 
the upper body does. Of 
course, death animations are 
all-body inclusive. 

So in Orbb’s case his hands 
have essentially become his 
legs, his body casing became 
his torso and his eyeball 
became his head. Setting up 
and attaching him to a biped 
in Character Studio turns out 
looking something like what 
we have in Figure 3. 

Notice that I didn’t give 
him arms and that the head 
and torso aren’t linked to an 


















































Still a form of computer game artist concentrate 


(just add imported beer) nearly 35 years in the making, Paul Steed (simply labeled 


“Steed” for easier marketability) will hopefully be applied to a new project by the time you read this. As usual, product information 





can be attained by dropping a line to psteed@idsoftware.com. 
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FIGURE 3. Orbb has been attached 
to a regular biped skeleton. 


underlying skeleton. The reason for this 
is that I intend to apply mo-cap data in 
the form of death animations and loco- 
motive animations mainly to the legs 
(arms), but I’m going to keyframe the 
fingers (toes), body and head anima- 
tions. | won’t even concern myself with 
what the unused skeletal parts of the 
biped do at this point since, given 
Orbb’s unique anatomy, they don’t 
matter (and I can’t delete them). 

So, taking a motion-captured run 
cycle I plug it into the character’s skele- 
ton (Figure 4). Something doesn’t quite 
look right here. If indeed those are sup- 


FIGURE 5. Rotating the legs will 
make them act more like arms. 
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FIGURE 6. Adding the mo-cap data to the reversed legs gives better results. 


posed to be arms, the elbows aren’t 
quite bending right, now are they? And 
those toes sure don’t look like prehen- 
sile digits. So my dilemma is how to 
make the legs act like legs while bend- 
ing like arms. I wonder if I can turn the 
leg around in the up axis? First [ll 
detach the mesh from the skeleton, 
then select the upper thigh and rotate 
it so the knee faces the opposite direc- 
tion (Figure 5). 

Cool. Now we can apply the same 
mo-cap run data to the now-reversed 
legs and see what it looks like (Figure 
6). This looks better. Next we reattach 
the mesh to the skeleton and keyframe 
those fingers...er, toes, doing some- 
thing cool like pushing off, flicking out 
as they push off, and so on. Doing this 
keyframe work on the hands results in 
poses like the ones shown in Figure 7. 





In adding keyframes to the fingers I 
try to exaggerate the motions a little. 


Just as a stage actor wears tons of make- 


up in order to be visible from the back 
row, amplifying animations is just as 
important in real-time games. Charac- 
ters running around in a game like 
Q3A usually don’t appear very large as 
you're trying to stuff rockets down 
their throat from afar. 

So after applying the mo-cap data to 
the arms and keyframing the hands 
and fingers, Orbb runs like he’s sup- 
posed to (Figure 8). I basically get to 
utilize all my animation files such as 
deaths, jumps, backpedals, walks, shuf- 
fles, or whatever, for Orbb’s animation 
set as it pertains to his legs and center 
of gravity. I have to make some gross 
adjustments to make sure his weight 
distribution appears correct, but overall 
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FIGURE 8. Mo-cap and keyframe data combined to produce our finished run cycle. 
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North America 800.447.2542 
Europe 800.4125.4125 
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Starting at $7500USD. Available on Windows NT and IRIX. 
Find out more about the most powerful 3D gaming tools 





they work out pretty well. Once the 
locomotive animations are in, | 
keyframe the head and body casing to 
react accordingly. 

This is just one of many possible situ- 
ations that can support both motion 
capture and keyframing. However you 
look at it, mo-cap is just as useful as 
keyframing if you have a basic under- 
standing of character animation and 
experience with keyframes. Rather than 
turning your nose up at an animation 
aid such as mo-cap, it behooves you at 
least to explore the potential benefit of 
the technology. After all, it’s just... 


—_ A Tool Like Any Other 


long time ago when I first started 
weight-training, | voiced my frus- 
tration at being so weak. This old bald 
guy from the monastery on base who 
was spotting me said, “Always remem- 
ber, Grasshopper, the weights are a 
tool, not a measurement.” The same 
applies to the methods and tools we 
use to create character animation with 
the computer. The character animator 
today no more becomes a talentless 
hack because he uses mo-cap than a 
master illustrator shows his inadequa- 
cies because he uses photographic ref- 
erence for his painting. 

I did my first animations back in 
high school when I'd have little stick 
people dancing along the edges of my 
textbooks running, fighting, somer- 
saulting or just plain being lewd. Then 
I got into comic books and began 
telling stories with splash pages and 
sequential story art (panels) a la Kirby, 
Buscema, Byrne, Golden and Miller. 
Comic art or comic strips are the most 
basic example of keyframes. While not 
as literal as flipping a page and watch- 
ing a little stick man come to life, each 
panel in a superhero comic is a static 
representation of a continuing dialog 
and dynamic flow for which your brain 
(instead of the computer) provides the 
“tween” frames. 

Learning to draw and portray char- 
acters in this fashion is perfect basic 
training for character animation, since 
it forces you to see things in your 
mind clearly enough to put them 
down on paper. This translation of 
thought to media and, more impor- 
tantly, the ability to recognize a suc- 
cessful translation is the key to better 





character animation because it gives 
you “the eye.” 

Simply put, having the eye means 
you can look at something and see it 
to be either one of two ways: right or 
wrong. If it’s right then you can move 
on to the next task. If it’s wrong, you 
keep working on it until you make it 
right. So many times someone shows 
me something or e-mails me some 
animation sequence and asks my 
opinion. When it’s so bad that I don't 
know where to start with a meaning- 
ful critique I simply ask, “Does it look 
right to you?” 

QUAKE 3: ARENA marks the first time 
I’ve personally dealt with mo-cap out- 
side of the annual obligatory dog-and- 
pony shows at Siggraph and other trade 
events. I decided to try the mo-cap 
route because it’s dead easy in 
Character Studio and for the simple rea- 
son our frame rate went from 10 FPS in 
QUAKE 2 to 15-25 FPS (depending on 
the animation). Turning to mo-cap 
makes sense as frame rates increase, 
since keyframing the subtle and nearly 
imperceptible nuances of humanoid 
character animation, if not difficult, is 
at least time-consuming. The difference 
between a six-frame run cycle and a 13- 
frame run cycle is obvious to say the 
least. Another reason is that my fellow 
animator Kevin Cloud decided to con- 
centrate on other art aspects and leave 
me to do all the models and animations 
(nice of him, wasn’t it?), so finding 
ways to save time became a priority. 

However, to say that I find myself 
forgetting how to keyframe because 
I’ve implemented mo-cap into the 
workflow is just plain ludicrous. Mo- 
cap is a start and, if anything, a rough 
timing guide to assist your keyframing. 
I have yet to implement any motion- 
captured animation without at least 
some keyframed adjustment. This is 
not a problem for me. 


The Mo-Cap Experience 


he first session I did was with Greg 

Pyros and his crew at Pyros Pic- 
tures. An amazing martial artist and 
actor, T.J. Storm, and a fellow actress, 
Bobbi, were the talent for my first run 
at making animations for the characters 
in Q3A. I learned a lot from the session, 
but since it was my first time I came up 
a little short in preplanning and accu- 
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rately predicting the implementation of 
the data in my animations. I also didn’t 
know Character Studio very well at the 
time and failed to exploit its strengths 
and allow for its shortcomings. Know- 
ing your pipeline and knowing all your 
software is crucial to successful mo-cap 
implementations. 

When I did my next session I went to 
House of Moves. The crew at HOM defi- 
nitely know their stuff and they were 
great to work with. I was quickly 
allowed to review the motions captured 
in crude wireframe playback to see if it 
was what I wanted. HOM also gave me 
videotape that matched the captured 
moves for both review and reference. 
There were differences dealing with 
House of Moves, but the most over- 
whelming difference was that I suited 
up to do most of the motions myself. 

I consider myself to be in reasonably 
good shape so I wasn’t afraid of the 
physicality of the shoot. Since I’m a 
ham at heart I knew I could act well 
enough to get reasonably expressive 
motions based on what I’d seen T.J. do 
at the earlier shoot, and more impor- 
tantly, to get what I wanted from the 
characters I had already created. How- 
ever, I fully realize that I’m in a unique 
position to have more freedom than 
most artists at most companies. It’s 
great being the modeler, animator, 
mo-cap director and mo-cap actor. I 
get to make sure I get exactly what I 
want and need to get the animations 
right. I enjoyed the HOM shoot so 
much that when I did my third session 
just recently I decided to be the “tal- 
ent” once again. 

This time however, I decided to try 
yet another company a whole lot closer 
to home. Located in the idyllic, rolling 
hills and fauna of Wimberly, Tex., near 
Austin, Kei and the crew at Locomotion 
Studios provided a comfortable, relaxed 
and professional atmosphere (except 
they didn’t have any beer stocked). 

The animations I went for this time 
were more scripted than the animations 
I did at the other two studios, so it was 
more important for me to give a better 
performance. Instead being pieced 
together and used by the characters 
during real-time game play, these ani- 
mations would be plugged into the 
characters mostly as-is to be used for 
rendered cutscenes. This is a great 
example of mo-cap saving you time on 
a project since the amount of work it 
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would take to make the subtle, expres- 
sive, realistic nuances I wanted in the 
animations would have taken far longer 
than I have to do them. Even in a 
worst-case scenario where the anima- 
tion is too wooden, keyframe augmen- 
tation can still save the day utilizing 
accurate timing if nothing else. 

In addition to offering immediate 
playback of the captured animation to 
see if it was what I wanted, Locomotion 
took the process one step further by 
filming the captures in MPEG format, 
giving me a digital movie of the perfor- 
mance. This proved extremely conve- 
nient, more so than videotape. 

Extremely accommodating like the 
other studios, they were tolerant 
when I got wacky. For example, one 
thing I did for a particular character 
with a three-jointed leg was to walk 
backwards in order to give it a creepy 
quality when it walked forward. To 
support this, the guys at Locomotion 
quickly and easily played back the ani- 
mation in reverse, which allowed me 
to adjust my performance until | got it 
right. Oh, and do you want to know 
the best thing about the session at 
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Locomotion? Soft reflector balls. Trust 
me, when you're covered with the 
hard ones, your potential for lots of 
pain while doing mo-cap is high. 


Just Where Do | Go for Mo-Cap? 


A I’ve said, time-saving is another 
attractive quality of motion cap- 
ture, but one that gets argued by artists 
because of the heavy cleanup required. 
That’s what mo-cap service houses 
such as Pyros Pictures, House of Moves 
and Locomotion are for. You can let 
them do the clean up instead. By the 
time you've made the space, spent the 
money and trained the artists to sup- 
port your own motion capture facility, 
the overall cost will be hard to beat by 
simply going to an expert. Having dealt 
with three of these companies that pro- 
vide such a service in the past year has 
given me a fast and comprehensive 
understanding of the motion capture 
process. Understanding this process 
from start to finish is a necessity if you 
plan on using mo-cap. 

Therefore, consider the following as 
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you tread down the motion-capture 
studio path. It could mean the differ- 
ence between success or failure: 
PREPLAN. By preplanning I mean story- 
board, either literally or in your mind, 
each move you plan on getting. Ensure 
there are one or two people who track 
and manage the process from start to 
finish (you, the artist, being one of 
them). Also, come up with good file 
names for your motions. I usually stick 
to a six-character naming convention 
because it leaves room for different ver- 
sions (takes) later on. Calculate the 
amount of time in seconds you esti- 
mate each motion will last and then a 
total for the shoot. Use that number of 
finished seconds as a starting point 
when you negotiate a price. 

GET A BID. Once your list is formed, start 
shopping around. Just be sure you 
have a very clear idea of what you 
want before presenting it to a mo-cap 
studio. Don’t be afraid to start a bid- 
ding war. These guys know how 
important patronage and word of 
mouth are in our industry. 

GET GooD TALENT. Although I really enjoy 
doing my own capture sessions, next 





Pro/E® .slp 
Renderman® RIB 
Renderware® 
Softlmage® hrc/dsc 
SAT 4.2 (ACIS®) 
Solid Edge® .Part 
STL. 

Strata® SPro v1.75 
trueSpace® 2 & 3 
USGS DEM 
VistaPro®” DEM 
VRML™ 1&2 
Wavefront® (+NURBS) 


1998 Newtek, Inc. & VSI 


NOVEMBER 
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time I’ll go back to paying some- 
one else to hit the ground and 
writhe around in real...er, mock 
pain. I’ve found the key to get- 
ting a good performance is to 
find actors who are almost 
mime-like in their expressions 
and motions. Also remind your 
actor to go full speed and not 
slow down during performance. 
This may not be something 
readily apparent, but overacting 
or being overly conscious of 
devices tracking your every 
movement can be very obvious 
in the finished data. I’ve had to 
cut up to ten percent of the 
keyframes in any given mo-cap 
file due to the actor being too 
measured in his or her move- 
ments, or make substantial 
tweaks because hands were used 
to break a fall (or to remove other glar- 
ing forms of anticipation). If you have 
the inclination and the ability, I highly 
recommend doing your own motions at 
least once. It makes you appreciate what 
you ask the talent to do in all those hard 
reflector balls. 

GET THE MOTION YOU WANT. Not much else | 
can say here. You're the client. You’re 
plopping down the cash (usually 30 
percent or so up front when you show 
up at the studio). You decide when the 
captured motion is right. Insist on a 
video or MPEG of the performance to 
review and just have around. If any- 
thing, it’s something to show your boss 
and co-workers. 

CHOOSE YOUR IN AND OUT TIMES. Basically, 
the in and out times are the points at 
which you want the motions you see 
on video to start and stop recording. 
This is obviously just so the mo-cap 
studio can calculate your total number 
of seconds captured, giving you exactly 
what you want when it happens. But 
never underestimate that little hitch or 
movement right at the beginning or 
end of a motion. While it’s prudent not 
to pay for useless seconds of idle move- 
ment, you might be able to take a part 
of one motion and use it in combina- 
tion with keyframes somewhere else. 
IMPLEMENT THE CLEANED DATA. Once the 
data is delivered, plug it into your char- 
acter and see how it works. I did cap- 
tures for a character and decided [| didn’t 
like the implementation ani just cut it 
from the list. Occasionally, some things 
really do just look better on paper. 
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Steed knows the importance of wearing many hats dur- 
ing the motion-capture process, including this one cov- 
ered with reflector balls at Texas’s Locomotion Studios. 





Pay THE GUY. Guess this is the bottom 
line, isn’t it? Rates vary, but if you 
shop around, like I’ve already suggest- 
ed, you'll get the fairest price. The 
price of motion capture seems to keep 
dropping every time I get it done. This 
trend will no doubt continue as tech- 
nology advances. 

Speaking of cost, it is something to 
consider. For a small developer, using 
a mo-cap studio may be cost-prohibi- 
tive, but I’d encourage you to check it 
out anyway. All the people I’ve 
worked with have been extremely 
accommodating and flexible when 
trying to get my business. If you pre- 
plan appropriately and know exactly 
what kind of motions you want, the 
end cost will reflect your degree of 
organization. 

Another key to making a mo-cap ses- 
sion successful is to involve the anima- 
tor who will be using the data. Sure, 
those clipboard-carrying, coffee-cup- 
toting producer types have their uses 
and can baby-sit the fiscally irresponsi- 
ble artist if they like, but at least one of 
the artists who will be working with 
the fruit of the session needs to be pre- 
sent during the shoot. 


Can't We All Just Get Along? 


ot too long ago, I read a couple 
negative commentaries on 
motion capture in a telephone-book- 
sized tome dedicated solely to charac- 


ter animation. This was the first time I 
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ever heard mo-cap referred to 
as “Satan’s Rotoscope.” What a 
load of crap. 

I hear statements like this 
and | think of that e-word — 
ego. Teams of people are 
responsible for games today, 
not individuals. Not to explore 
the possibilities and benefits of 
a new technology because you 
want the pleasure of proclaim- 
ing you did it all from scratch is 
part of the inanity that results 
in very late products being 
shipped. Sure, given all the 
time in the world, any anima- 
tor worth his salt can create 
convincing and supremely real- 
istic character animation. Well, 
we all know how much time we 
have to do our animations, 
don’t we? 

But, what the hey. Let’s just say fora 
second that mo-cap is evil. The bane of 
the real artiste. If that’s the case, then 
why not just toss that computer alto- 
gether and go back to traditional cel 
art animation and just scan the art in? 
Oh, but that would mean you'd have 
to use a scanner. Since that evil con- 
traption digitally captures images that 
could be used in game art, such as tex- 
ture maps, we should probably get rid 
of that bit of demonic technology as 
well. While you’re at it, what about 
digital cameras, model digitizers, 
heck...even photographic reference of 
any sort? Maybe all example of mod- 
ern techniques or technologies that 
assist the artist in his ability to meet 
his deadlines with work that (gasp) is 
sometimes better than he could have 
achieved on his own should be con- 
signed as products of the nether realm. 

The purists would secretly be not too 
unhappy about this because then they 
could weed out the real artists from 
those pretentious wannabe keyboard 
jocks. Then they could beat their chests 
in pride and reaffirm their prodigious 
training and stature. 

Technophobia has no place in 
today’s world of computer game devel- 
opment. Motion capture is here to stay 
and will antiquate keyframing about as 
quickly as electronic documents have 
turned our work environment into a 
“paperless” office. In the right hands, 
mo-cap is the perfect way to aid and 
enhance the keyframe animator, not 
replace him. @ 
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by Omid Rahmat 





A Tale of Two Channels 





Even Nintendo’s Game Boy has shown 
phenomenal growth in 1999 and is 
attracting new titles and developers to 
the color version, while the next- 
generation, 32-bit Game Boy “Advance” 
is slated for release late next year. All 
these comparisons of platform tech- 
nologies aside, the biggest obstacle to 
success in the PC gaming market is the 
structure of the PC business, which is 
built around the sales of PC hardware to 
businesses and education outlets. 
Games may be ubiquitous, but the PC 
industry still sees the game industry as a 
marginal interest, and sometimes solely 
as a means to sell the latest CPU. 
Examining the market of console game 
users and the channels for console prod- 
ucts is a sobering lesson in how far the 
PC industry has to go to become con- 
suMer-savvy. 

The PC game business has always 
been hampered by a lack of shelf space 
and sufficient sales outlets. This situa- 
tion is unlikely to be resolved while the 
market remains driven by the upgrade 
cycles of Microsoft and Intel. In the 
meantime, the console gaming market 
is benefiting from penetration into 
both traditional retailing channels and 
existing PC sales channels. 


Channels Young and Old 


hile online sales of PC products 
is considered to be a hot area of 
growth, the vast majority of sales still 
come from third-party retailers and dis- 
tributors who rely on their expertise 
with applications to serve a desired 
market. It’s rare to find a reseller or sys- 
tem integrator that is focused on 
garnes. In contrast, console products are 
predominantly retail-based and require 
no third-party support or intervention. 
For PCs, there are more than 100,000 
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companies in the U.S. alone that act as 
middlemen for computer manufactur- 
ers, and who supply systems, upgrades 
and services to users. In such a large, 
competitive market, specializing in 
hardware sales to game players would 
make little sense, and trying to compete 
in the arena of PC gaming software is 
unlikely to enliven any reseller’s bot- 
tom line. 

By contrast, a fully configured net- 
work of systems for a small business or 
corporate customer has potential for 
lucrative service and support contracts, 
or may be solely beneficial in selling a 
reseller’s software expertise. So, while 
the $125 billion in sales that the PC 
channels produce is an impressive 
number, it’s spread across a vast mix of 
dealers and resellers. These consist of 
value-added resellers (VARs), retailers, 
distributors, systems integrators (SIs), 
mom-and-pop stores, and everything 
from a single-person consultancy to big 
service companies such as EDS. Stacked 
up against these hardware-driven dis- 
tribution channels is a console business 
driven by cute game characters and 
mass-market promotions. 

Simply put, PC channels are relative- 
ly young compared to the retail chan- 
nels that console games have penetrat- 
ed. PC channels are as old as the PC, 
while retail channels date back to 
before the electronic age. This points 
out the gaping chasm of consumer 
savvy between traditional PC sales 
channels, and the retailers that thrive 
on N64, PSX, and Game Boy products. 
Furthermore, the next generation of 
console products promises to constrict 
the PC gaming market by providing 
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C gaming appears to be the technological peak of game development. 
However, the advent of Sega’s Dreamcast, Sony’s marketing of Playstation 
2 technology, and the intriguing prospects of Nintendo’s Dolphin system 


have helped to promote greater anticipation for the console. 


powerful platforms with multimedia 
and online capabilities. Next-genera- 
tion consoles may not be PCs, but they 
don’t aim to sit on someone’s office 
LAN, either. 


The Console Player's Choice 


t the third annual Electronic 

Gaming Summit this past August, 
Ziff-Davis announced the results of the 
Video Gaming in America research 
report. This report found that purchase 
impact is influenced more by brand 
power of a character or game than by 
the knowledge of the publisher or 
developer. Surprisingly, the buying 
habits of game players, according to the 
report’s findings shown in Chart 1, 
point out their preference for discount 
stores where impulse buying and pric- 
ing play a key role. Console games seem 
to have better branding and get into 
the places where the most buying 
occurs. This is despite the fact that at 
places like Wal-Mart, PC games have to 
be priced below $20 to qualify for sig- 
nificant sales. If that weren’t bad 
enough, the reputation of consoles as 
high-technology products, which is 
reflected in the sales of console games 
through computer superstores. 

The other advantage that the console 
market has is rentals. “Core” game play- 
ers (defined in the report as those con- 
sumers who purchase two or more 
games per month) are averaging more 
than three rentals per month, while 
“casual” players (defined as those who 
purchase fewer than two games per 
month and play fewer than four times 
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per week) average about 1.4 
rentals per month. The real 
kicker is purchase rates after 
rental are 84 percent and 65 
percent respectively for core 
and casual players. Video 
rental outlets can devote any- 
where from 10 to 20 percent 
of their shelf space to games, 
but generate in excess of 
those figures in percentage of 
revenues from rentals. There 
is really no mechanism in 
place, or likely to be put in 
place, to create the same 
rental opportunity for PCs. 
The PC always has the benefit 
of the limited demo software 
package bundled with game 
magazines and available for 
download, but these options 
pale in comparison to being 
able to take a game home to 
play in full for three days. 
Another interesting find- 
ing in the report is the influences on 
players’ purchasing choices across core 
players, casual players, and “average” 
players (defined as consumers who pur- 
chase fewer than two games per month 
but play four or more times per week), 
shown in Chart 2. Friends, television, 
and in-store game demos played a key 
role here. In-store demos of PC games 
are unlikely to happen anytime soon, 
unless you have a publisher with a very 


CHART 2. Consumers’ sources for videogame purchasing information (source: Ziff-Davis). 


significant marketing budget to spend, 
or PCs end up costing $100, and you 
can load 10 games within 60 seconds. 


The PC Branding Problem 


pad C games, with some exceptions, 
tend to be more sophisticated sim- 
ulations and immersive environments. 
As a result, PC games lack some of the 
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CHART 1. Game players are shopping across all outlets (source: Ziff-Davis). 
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“cute” character brands of console 
games. At a more specialist level, the PC 
has programmers like John Carmack 
and designers like Sid Meier, but the 
console industry has Shigeru Miyamoto 
and David Perry. 

To reconcile these two worlds, PC 
game channels have to get closer to 
the console market in terms of mar- 
keting sophistication and audience 
appeal. PC gaming will not ultimately 
die, but it will become cor- 
nered, and that will affect 
the flow of new talent into 
the industry. That in turn 
would affect innovations in 
technology and titles. It 
looks like the console mar- 
ket has finally grown up, 
and now it’s time for the PC 
market to do the same. But 
it won’t happen until the 
gaming industry figures out 
how to break the infrastruc- 
ture of PC sales channels. 

Recently, the Good Guys 
chain of electronics stores 
announced it was ceasing PC 
sales, CompUSA said it would 
close some of its stores, and 
OfficeMax has felt the drain 
of lower PC prices and prof- 
its. Meanwhile, displays of 
console games and hardware 
in CompUSA stores continue 
to grow. & 
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you just don’t hear much about. 


While specific techniques for program- — 
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pull back the covers to help 
developers squeeze the last 
ounce of performance out of the 
machine. We hope that this arti- 
cle will help N64 developers do 
just that, and encourage other 
developers to explore N64 pro- 
gramming. 

After a quick discussion of the 
N64 architecture, we’ll dig 
down deep and design some 
custom Reality Signal Processor 
(RSP) microcode, which tessel- 
lates a Bézier surface as shown 
in Figure 1. The RSP is a very 
powerful custom chip in the 
N64, and until now the details 
of programming this chip have 
been kept secret. In a sense, we 
at Nintendo have decided to let 
the cat out of the bag. You'll get 
a feel for the incredible power of this 
chip and see why N64 is capable of 
great 3D graphics with features that 
still aren’t available in consumer 3D 
cards. 


Nintendo 64 Architecture 


he Nintendo 64 is designed around 


two main processing components 
(Figure 2). These two elements are a 
MIPS R4300i CPU, and the Reality Co- 


Processor (RCP), which is a custom chip. 


The simplicity of this architecture 
makes N64 programming very straight- 


forward. In addition to these processors, 


the N64 contains 4MB of Rambus 
DRAM (RDRAM), four controller ports, 
and a cartridge port. The memory is 


expandable and a 4MB Expansion Pak is 


currently available. 
The N64’s custom RCP runs at 
62.5MHz. It is pri- 
marily composed 
of two parts: the 
Reality Signal 
Processor (RSP) 
and the Reality 
Display Processor 
(RDP). Che KSP 
processes display 
lists which are sent 
from the CPU. It 
performs all 
matrix and vertex 
computations and 
outputs triangle 
commands to the 
ROP. [ne RDP 
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FIGURE 2. The Nintendo 64 architec- 
ture is simple and elegant. 
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FIGURE 1. This Bézier surface has been tessellated by 
the microcode we develop in this article, and rendered 
by a Nintendo 64. 





takes this information, loads the tex- 
ture cache from RDRAM, and renders 
fully MIP-mapped, anti-aliased, Z- 
buffered triangles to the frame buffer. 
This design leaves the CPU free to per- 
form physics calculations, advanced 
artificial intelligence, sound process- 
ing, and other game functions. 


RSP Architecture 


he RSP is modeled on a general- 

purpose 32-bit RISC processor. It 
includes 4KB of memory for code 
(IMEM) and 4KB of memory for data 
(DMEM). Programs which execute on 
the RSP are known as microcode. 
Nintendo provides a standard suite of 
microcode to all N64 developers, 


including 3D transformation and light- 
ing code, line-drawing code, sprite rou- 


tines, and audio processing. Due to 


1999 


MipLevel 





special features of the RSP, it is 
very well-suited for computa- 
tionally heavy tasks such as 3D 
graphics calculation and audio 
mixing. 

In addition to 32 32-bit 
scalar registers, the RSP 
includes 32 128-bit vector reg- 
isters. These vector registers 
can be addressed in a variety of 
ways, but they are ideally used 
as eight shorts (also called vec- 
tor slices). Each slice has a 48- 
bit accumulator associated 
with it that can be used to 
store intermediate results. 
Using the vector registers and 
accumulators, a vector opera- 
tion can be performed which 
multiplies two vectors and 
adds the result to the current 
accumulators, giving 16 calculations in 
one cycle. 

The RSP can actually execute a vector 
operation and a scalar operation each 
cycle. This means that it’s possible to 
do 17 calculations per cycle. With care- 
fully tuned microcode, it is possible to 
reach a maximum of just over one bil- 
lion operations per second. 


The Microcode 


his high-speed programmable 

architecture was very forward- 
thinking at the time the Nintendo 64 
was designed. It has enabled Nintendo 
to provide a set of standard microcode 
libraries which make 3D programming 
easier for the novice. At the same time, 
elite programmers are able to code up 
special routines which are optimized 
for their own games or enable unique 
functionality. 
During the life span 
of the N64, the 3D 
performance has 
nearly doubled as a 
result of microcode 
optimizations. 


TileNum 


T scale 


Microcode 
Execution 


FIGURE 3. An example command 
from the standard N64 3D graphics 
microcode. This command turns on 
texture mapping using a specific tex- 
ture tile. 


irst let’s talk a 
little about the 
structure of microc- 
ode and how to use 
it. Microcode is exe- 
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cuted through the use of an RSP 
task. Tasks are command lists 
(graphics display lists or audio 
commands) which indicate a 
series of operations for the 
microcode to perform. They are 
executed in parallel with the 
CPU. In order to start an RSP 
task, you create the command 
list and pass it to the RSP along 
with pointers to the microcode 
and various buffers that the 
microcode needs. Then you call 
a simple function to start RSP 
execution and control is imme- 
diately returned to the main pro- 
gram while the RSP begins pro- 
cessing commands. 

The RSP can communicate 
with the RDP or CPU during 
execution if necessary. For 
example, most versions of the 3D 
microcode communicate with the 
RDP, feeding it triangles and other 
data to render to the frame buffer. 
Other versions of microcode commu- 
nicate with the CPU when data is 
ready. For example, the Z-Sort microc- 
ode can be set up to alert the CPU 
after a number of objects have been 
processed so that the CPU can work 
on these objects in parallel. When the 
RSP completes the task, it signals the 
CPU so that the user program can 
send the next RSP task or use this 
information for synchronization. 


The Command Loop 


he microcode command loop 

sequentially goes through com- 
mands which have been DMA’d into 
DMEM from the command list. Simi- 
lar to assembly language instructions, 
the commands have bitfields which 
indicate the RSP function desired. In 
the microcode command loop, the 
opcode and subopcode bitfields are 
masked off and used as an offset into 
the function jump tables (also stored 
in DMEM) to determine the IMEM 
function location. 

In the standard graphics microco- 

des, each command is a 64-bit double- 
word. The opcode and subopcode are 


contained in the upper bits, and lower ately 
bits are reserved for data being passed returned 
as function parameters as shown in to the 
the example in Figure 3. The data bit- micro- 
fields are masked off in the main loop code. 
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FIGURE 4. Bézier surfaces are defined in a biparamet- 
ric space. Sixteen control points are used to define the 
surface completely. 





and stored in separate registers before 
jumping to the function requested. 


The DMA Engine 


he RSP includes a set of registers 

which control the DMA engine. 
Since there may be multiple requests 
for DMA pending, the microcode must 
check the DMA Busy register before 
submitting its request. If a request is 
being processed and there is already 
another request pending, the micro- 
code must wait 
before sub- 
mitting a 
request. A 
request is 
made by 
altering the 
DMA Source, 
DMA Destination, 
and DMA Length 
registers. Once the 
length is written to the 
DMA Length register, the 
DMA engine queues the 
request and begins the 
transfer if no requests 
are pending. The 
transfer executes in 
parallel with the 
RSP so control 
is immedi- 











Using Curved Surfaces 


wa this basic under- 
standing of the N64’s 
workings behind us, let’s move 
on to the main focus of this 
article, using curved surfaces. 
Curved surfaces are not sup- 
ported in the standard N64 
microcodes. But if you want to 
render curved surfaces, it makes 
a lot of sense to do the heavy 
computations required on the 
vector processor. Now, we’re 
not actually going to render 
curved surfaces. We'll take a 
curved surface representation 
and tessellate the surface into 
polygons which the N64 then 
renders. 

For our purposes here, we are 
going to use Bezier surfaces. A Bezier 
surface is a curved bicubic surface, sim- 
ilar to Hermite surfaces, B-spline sur- 
faces, and NURBS. The Bézier is mathe- 
matically complex enough for us to be 
able to create interesting surfaces, 
while not being so difficult to compute 
that we're only going to be able to doa 
couple per frame. If you need to brush 
up on curved surface technology, 
check out the list of references at the 
end of this article. 

There are a number of algorithms 
we could use to tessellate a Bézier sur- 
face. First, let’s quickly look at the 
standard equation and 
the algorithm 
we'll use in 
the micro- 
code. 


























If 
you're 
inter- 
ested in 
the back- 
ground of 
Bezier surface 

algorithms and 
want to learn more about why I’ve 
chosen this one, please see the 
expanded version of this article (with 
Bezier surface derivation) on 
Gamasutra.com. 


http://www.gdmag.com 
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Bezier Surface Equation 


Bézier surface is a parametric sur- 

face (u,v = [0,1], [0,1]) defined by 
its 16 control points p,; which form a 
4x4 grid, as shown in Figure 4. The 
common form for representing this 
surface is: 


= ¥ p,B,(u) u)B 


i=O j=0 


Q(u,v) 


The functions B(u) and Biv) are the 
Bernstein polynomials which are also 
used for Bezier curves. 

The edges of a Bézier surface are each 
Bézier curves. Since only the end con- 
trol points of Bezier curves lie on the 
curve, we can extrapolate that the cor- 
ner points of the surface are the only 
control points which lie on the surface. 
All twelve of the other control points 
influence the shape of the surface, but 
are not on the surface itself. For this 
article, we’ll create a microcode that 
tessellates a Bezier surface into an 
8x8 grid of quadrilaterals. 


Tessellation by Evaluation 


he most direct way to slice a 
Bézier surface into polygons 
is by calculating the above Q(u,Vv) 
double summation on a regular 
grid. Performing this in a very 
optimized way, each surface 
vertex we calculate requires 54 
additions and 108 multiplies. 
That’s a lot of work to do 
when we're planning to create 
a 9x9 grid of vertices. 


Central Differencing 


he way we're going to generate 

points on the Bezier surface in 
this article is through the use of central 
differencing. Central differencing gives 
us an easy way to find the midpoint of 
a Bezier curve without having to keep 
track of control points for each sub- 
curve. We can split the edge curves at 
their midpoints, and then split the sur- 
face across these midpoints to create 
four subsurfaces. This process can be 
repeated recursively to create an arbi- 
trarily fine mesh. (For details on this 
algorithm please see the previously- 
mentioned article on Gamasutra.com, 
or Brian Sharp’s series of articles on 


GAME DEVELOPER 


curved surfaces, June-July 1999.) 

The central differencing algorithm 
has a hefty initialization cost due to 
the computation of second partial 
derivatives (Quu, Qvv, Quuvv) at each 
corner control point. But every curve 
subdivision after that will only cost us 
18 additions and 18 multiplies. The 
memory footprint is 24 bytes per subdi- 
vision, and there are 77 subdivisions 
necessary to create our mesh. This will 
fit in our 4KB DMEM nicely. 


Writing the Tessellation Microcode 


ty ow that we’ve chosen the algo- 
rithm to tessellate the surface, 
let’s get back to work on the microcode 
itself. The first things 
we need to fig- 
ure out are the 
commands 
we need 
and the 
com- 
mand 
struc- 
ture. 
We're 
going to 
use a 
64-bit 
double 
word for our 
command size. 
That will give us 
plenty of 






















room to store the data for each com- 
mand inside the instruction. The com- 
mands and parameters necessary for 
our tessellation microcode are: 
1. Set RSP segment (segment number, 
physical address). 
2. Load control points (segment 
address). 
3. Perform tessellation. 
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4. Save surface vertices (segment 

address). 

5. End display list. 

I’ll describe these commands further in 
a moment. 

Since we only have five commands, 
we can just use a 3-bit field for the 
opcode. Fortunately, the standard 
graphics microcodes all use a 3-bit 
opcode field and 6-bit subopcode field, 
so we'll use that. But we’ll just wedge all 
our instructions into the subopcodes for 
one primary opcode. Then we can reuse 
a lot of the main command loop rou- 
tines from the standard microcodes, 
including the display list DMA routine 
that loads commands into the DMEM 
buffer for us. The low bit of the opcode 
field and subopcode field are not used. 
Since microcode function addresses 
stored in DMEM take up two bytes 
(address range 0-4095), our jump table 
should be indexed on even bytes only. 
Not using these low bits ensures that we 
have an even index without performing 
a shift or multiply for every command. 

The parameters for our commands are 
pretty straight-forward. The most com- 
plicated command sets a segment regis- 
ter for address computations. It requires 
a segment number and physical address. 
We’re using a 16-address segment table 
in the RSP, so it’ll take four bits to hold 
the segment number. The addresses are 
32 bits, so we’ll use the second half of 
the 64-bit double word for the address. 
Then we'll use the upper nine bits for 
the opcode and sub- 
opcode fields 

and follow 
it with 
four bits 
for the 
segment 
address. 
You can see 
our command 
structure in Figure 5. 


Getting Data In and Out 


= efore we code up the tessellation 
algorithm, let’s figure out how to 
get data in and out of DMEM. The “set 
RSP segment” command fills an entry 
of our 16-entry segment/offset table, 
which is stored in DMEM. This table 
makes some programming tasks easier, 
such as swapping the frame buffer each 
frame. The segment table stores 24-bit 
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CG Pear and Tangerines, with Grapes, by Jeremy A. Engleman 


Real or REALimage ? 


Artist Jeremy Engleman used 3D Studio MAX to create this 
incredible still life. Like other CG artists and designers, Jeremy is constantly 
pushing the limits of technology to produce more striking images. 


"I'm trying to explore a painterly nature through CG media. This does not mean 
I am trying to make CG look like a painting through the use of ‘art’ filters, but 
rather I am trying to identify what can be painterly about computer graphics' 
own nature. The grain in the image above is the result of multiple conversions 


to indexed palettes.” 


Developing imagery like this demands a high-performance graphics accelerator 
like the E&S Tornado 3000 . Designed for professional, OpenGL applications 
and powered by Evans & Sutherland’s REALimage® technology, Tornado meets 
the exacting requirements of today’s artists, such as high-polygon-count mod- 
eling and fast texturing performance. If you're an artist using 3D Studio MAX, 
Softimage 3D, Maya, LightWave 3D, Mirai, or Houdini, unleash your creativity 
with E&S Tornado 3000", the power behind the scenes. 


To find out more about Evans & Sutherland graphics accelerators or to purchase 
on line through ESDirect, visit our web site at www.es.com/wg. 


EVANS & SUTHERLAND 


the power behind the scenes 








FIGURE 5 
the structure of standard N64 microcode com- 

mands. We use this structure for all of our com- 
mands. 


offsets which are added to any address 
sent to the RSP. The segment table 
index is stored in bits 24-27 of the 
addresses passed in. The low 24 bits of 
the segment address are added to the 
24 bits stored in the segment table. 
Since our physical address range is 
O-Ox007fffff (8MB), 24 bits is enough. 

Prior to tessellation we need to load 
the control points into DMEM. Our 
“load control points” command simply 
takes an address as a parameter. The 
address is passed to the segment 
address translation routine, which uses 
the segment table to convert the 
address to a physical address. The DMA 
engine is called to bring the 16 control 
points into DMEM from this physical 
address. 

After tessellation, we need to save 
the surface vertices we’ve computed, 
using the “save surface vertices” com- 
mand. We'll pass in an address and the 
segment address translation routine 
will convert it to a physical address. 
That physical address is used to pro- 
gram the DMA engine to copy our 81 
surface vertices to RDRAM. 

The “end display list” command sim- 
ply flags the RSP to quit. It executes a 
break, which signals the CPU, and 
alerts Our main program. 


Data Formats 


he first thing our “perform tessella- 

tion” command does is perform a 
simple translation from control point 
format to surface vertex format. So let’s 
talk about these formats. 

The Nintendo 64’s standard vertex 
format uses 16-bit coordinate ranges, 
which are s15 quantities (one sign bit 
and 15 integer bits). This gives vertex 
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. Our command structure is similar to 
















NOVEMBER 1999 


coordinates an effective range 
of +/— 32KB. It makes sense for 
us to use this same format for 
control points, but since we’re 
just tessellating, we really only 
need the point position. Rather 
than wasting the extra space 
for colors and texture coordi- 
nates when we DMA the con- 
trol points into DMEM, our for- 
mat will only represent the x, y, 
and z position as signed shorts. 
The surface vertex format is 
more complicated. The central 
difference algorithm describes 
four sets of values that each ver- 
tex needs to track. These are: 
1. Q(u,v): Position 
2. Qi(u,Vv): Second partial derivative 
in u at this vertex 
3. Q\.(u,v): Second partial derivative 
in v at this vertex 
4. Quuvy(u,Vv): Second partial derivative 
in u of the second partial deriva- 
tive in v at this vertex 
All of these values are vectors of x, y, 
and z. Since the vector slice size of the 
RSP is 16 bits, and the control point 
coordinates are 16 bits, we’re going to 
stick with 16 bits for these coordinate 


LISTING 


include them for data alignment. 


struct ControlPoint . 


values as well. We’ll have to tweak our 
math to minimize overflow and under- 
flow, but it will pay off in performance. 

One final note on formats. Each vec- 
tor register contains eight vector slices. 
But each of our points contains three 
values (x, y, and z). We're really just 
going to make things confusing if we try 
to stuff two of three coordinates from 
one vertex into a vector register, along 
with two other vertices. So let’s insert a 
junk (we’ll call it j) field at the end of 
each of these vertices. This will also give 
us much better alignment in DMEM. 

Now that we have our formats 
defined as in Listing 1, it’s a simple task 
to convert from one to the other. Actu- 
ally, all we need to do is copy the 64 
bits from each corner control point (x, 
y, Z, and j) into the beginning of each 
corner surface vertex. 


Corner Initialization 


Ow we need to compute the sec- 
Re ond partial derivatives described 
above for each corner of the surface. 
Fortunately, the second partial in u 
and the second partial in v at each 


Formats for data storage in DMEM. The j fields are unused, we 











s15 iL ys 2 be a 
5 | 
struct SurfaceVertex { _ 
s15 ak, Oy, G2, Gj; a. 
s15 quux, quuy, quuz, quuj; = = 
s15 qvvx, quvy, quvvz, quvvj; oe ee a 
s15 quuvvx, quuvvy, quuvvz, quay) 


LISTING 
processing. 


# Load the vector registers with point “ 


vload vectora, P[0,0], PL0,0] 
vload vectorb, P[1,0], P[0,1] 
vload vectorc, P[2,0], PL0,2] 


# Do vector computations to simultaneously compute 4 | 


vadd vectord, vectora, vectorc © 
vmul vectore, vectorb, veonst{5] 
vadd vinter, vectord, vectore © 
vmul v00, vinter, veonst{3] 
vstore2 v00, vOQuu, vOOwy 
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corner control point can be computed with similar equa- 
tions that use different points. Here are the equations to 
perform at control point (0, 0): 


Q,,,(0, 0) = 6(P,, = aliy " a 


Q,,,(0, 0) on 6(Py, _ 20 + Fa) 


We need to do this computation in x, y, and z for each 
equation. This is a great place to take advantage of vector 
processing. We’ll do this operation in parallel, computing 
both equations for x, y, and z simultaneously. First, we load 
both sets of control point positions into the vectors, as 
shown in pseudocode in Listing 2. Then just a few vector 
computations are performed and all coordinates are simul- 
taneously calculated. 

Note that we have the constants —2 and 6 stored in a vec- 
tor constants (vconst) register, which makes it easy to multi- 
ply each slice in another vector by each 
scalar. Using vector processing we’ve 
reduced two additions and two 
multiplies for each of six coordi- 
nates to just two additions and 
two multiplies total. 

We can perform this same 
PYOCESS TO CONIPULE Gann 
But we'll have to pair up 
the operations. We have 
four control points, the 
corner points, which we 
need in order to calcu- 
late Quiwy. We can com- 
pute two separate con- 
trol points 
simultaneously by jam- 
ming them into the same vector and doing 
vector operations. So we'll perform this 
process twice in order to compute Q,,,,y for 
all four points. 


Surface Subdivision 


code simplicity, we’re going to subdivide 
the surface iteratively, not recursively. We’re going to 
subdivide many times, so let’s make a function out of it. 
What do we need to pass to this function? Well, we’ll need 
the data for the endpoints of the curve we’re splitting, and a 
du value which is the distance in parametric space from the 
midpoint to the endpoint. This is 0.5 for our first subdivi- 
sion. For simplicity, we’ll pass in the value (du)*/2 so we 
don’t have to compute the square and multiply by one-half 
each time we use the function. We’ll also stuff this value in a 
vector slice so that we can use it in vector computations. 
We'll call the vector which contains this value vecdusghalf. 
Our function ends up looking like this (there will be one for 
u-curve splits, and one for v-curves): 
void tesselSubdivide[U|V](Vertex v0, Vertex v1, Vector vecdusghalf) 
The microcode for the tesselSubdivideU function appears in 
Listing 3. The function tesselSubdivideV will be very similar. 
The first thing you'll notice in this code is that we block 
together the Q,,, and Qi, computations. We also block 
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together the Q and Q,, computations. That’s because both of 
these are very similar computations. For Q,, and Quy we’re 
doing this: 


Q,,(U) + Q,,,(U, } 
ye: 


Qi (Myay) = Lente) + Reals} 


The computations for Q and Q,, depend on the prior com- 
putations, so we do them second. They look like this: 


a a 


( 0 , vil i ; 
Q(U nic) - ey - =. x CF ital 


lita) = Q,, (Uo) + Q,, (U4) 7 (du) 


-_ a (en 
Most of the opcodes you see in the microcode 
listing make intuitive sense. But one that 
bears explaining is vmudm. The RSP pro- 
vides many multiplication opera- 
tions. They vary depending on the 
sign of the operands and whether 
the operands are fractions or 
integers. The vmudm opera- 
tion performs multiplica- 
tion of signed integers 
by unsigned fractions. 
The resulting integer 
part of each vector slice 
computation is stored in 
the destination vector reg- 
ister (first operand), and 
the 32-bit integer/fraction 
results are stored in the 
accumulator slices. 
3 This microcode currently is 
not optimized for dual process- 
ing, nor for accumulator storage 
of intermediate results. Vector 
loads and stores are scalar opera- 
tions, so we could easily tighten this 
microcode up by executing loads and stores in parallel with 
vector operations. 


Performance Figures 


tenders a regular grid of points on the Bézier surface 
using the standard double sum equation is a not a very 
efficient way to tessellate. Using floating-point arithmetic on 
the CPU, this process took 272,500 CPU cycles. While cen- 
tral differencing has a large performance cost at initializa- 
tion, the subdivision step is very fast. Implemented on the 
CPU, it takes 70,400 CPU cycles to tessellate our surface. 

When we moved this algorithm to the RSP, we made some 
sacrifices. We used 16-bit fixed-point arithmetic and took a 
hit for DMA-ing data to and from the RSP. But our algo- 
rithm, including RSP load and save time, runs in just 16,600 
CPU cycles. And the CPU itself is free during this process to 
do other computations. 
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N64 Optimizations Keep the 
Platform Fresh 


ww examined how Bézier sur- 
faces can be implemented on 
the N64 using a central difference tes- 
sellation algorithm in microcode. The 
payback we got for choosing a more 
efficient surface tessellation algorithm 
and pushing it onto the RSP was sub- 
stantial. 

Technically, the N64 is still a power- 
house. Programming the microcode 
and taking advantage of vector pro- 
cessing gives developers the ability to 
implement algorithms that aren’t fea- 
sible on much bigger and faster CPUs. 
In addition, learning to program the 
N64 now will give developers a big 
advantage when it comes to next-gen- 
eration console development (includ- 
ing Nintendo’s upcoming system, cur- 
rently known as Dolphin), many of 
which use vector processing. If you're 
interested in becoming an N64 devel- 
oper, or if you are an N64 developer 
and you want to know about microc- 
ode development kits, please contact 
Nintendo by sending e-mail to 
support@noa.com. & 
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LISTING 3. Microcode for the tesselSubdivideU routine. 


SECAEEAERELSAEASEEETASREASEESOEASEEAGREAEREREEESEEEREEDS 
# tesselSubdividel 


= 


# Subdivide this curve in the U direction 


a 


# Surface Vertex structure offsets 


.symbol VERTEX_POS, 

-symbol VERTEX_UU, 8 
symbol VERTEX_VV, 16 
symbol VERTEX_UUVV, 24 


# Register aliases 


.name pnew, $10 
.name pminus, $11 
.name pplus, $12 
name vecdusghalf , $v6 
.name vecminus, $v7 
.name vecplus, $v8 
.name vecuus, $v9 
.name vecuushaLf , $v10 
.name vecposvvsinter, $vil 
.name vecposvvshalf, $v12 
name vecmulleduus, $v13 
.name vecposvvs, $vi4 
ent tesselSubdivideU 

tesselSubdivideU: 






# Position of input right surface vertex oo 
# Vector which contains 0.5*du*du in sliceQ 


# Vector for storing left surface vertex info 


# Vector for storing right surface vertex info See 


# Temp vector for UU and UUVV computation 
# Final results of UU and UV computation 
# Temp vector for POS and VV computation 
# Temp vector for POS and WV computation 
# Temp vector for POS and VV computation 


# Final results of POS and VV computation ee. 


# Do quu and quuvv computations together 


dv vecminus[0], VERTEX_UU(pminus) 

ldv vecminus[8], VERTEX_UUVV(pminus) 

dv vecplus[0], VERTEX_UU(pplus) 

ldv vecplus[8], VERTEX_UUVV(pplus) 

vadd vecuus, vecminus, vecplus # Add endpoints 
vmudm vecuushalf, vecuus, vecconst[1] # Mul by one-half 
# Do qpos and qvv computations together 

dv vecminus[0], VERTEX_POS(pminus) 

ldv vecminus[8], VERTEX_VV(pminus) 

ldv vecplus[0], VERTEX_POS(pplus) 

dv vecplus[8], VERTEX_VV(pplus) 

vadd vecposvvsinter, vecminus, vecplus # Add endpoints 
vmudm vecposvvshalf, vecposvvsinter, vecconst[1] # Mul by one-half 
vmudm vecmulleduus, vecuushalf, vecdusqhalf[0] # uus/2 *(du°2)/2 
vsub vecposvvs, vecposvvshalf, vecmulleduus # Subtract... 


# Store everything 


sdv vecuushalf[0], VERTEX_UU(pnew) 
sdv vecuushalf [8], VERTEX_UUVV(pnew) 
sdv vecposvvsl0], VERTEX_POS(pnew) 
jr return 

sdv vecposvvs[8], VERTEX_VV(pnew) 
end tesselSubdividel 
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MANAGEMENT — 


The Big Squeeze: 











But resource management is much 
more than just dealing with size con- 
straints. You also have to properly allo- 
cate and free resources, which, if 
ignored, can quickly turn into hiding 
places for numerous bugs. Fortunately, 
there are ways to deal with these prob- 
lems. It just requires planning and 
implementing some helpful tools. 
First, let’s see what we’re getting our- 
selves into when we start talking about 
developing for a console. For this article, 
my focus is on the main memory, so 
we'll ignore video and sound memory. 
The current champ of the console 
wars is the Sony Playstation, which 


esource Management 
uring Your Console Port 


by Michael Saladino 


means that if you’re thinking about 
developing for consoles, you’re proba- 
bly considering this system. The 
Playstation’s massive consumer market 
is the good news, but the bad news is 
that its market is the only big thing 
about it — the system itself is very lim- 
ited when it comes to resources. The 
Playstation is a small system with only 
2MB of primary memory. The 
Nintendo 64 isn’t much better at 4MB. 
The newest kid on the block, the Sega 
Dreamcast, comes to the table with a 
more impressive 1}6MB of memory but 
it will sometimes have Windows CE 
taking a slice of that space. (Also, the 

















eveloping games for consoles often requires tight 
resource Management. Trying to fit all your 
textures, sounds, and polygons onto the 
machine is difficult enough, but then 
consider that your monsters, explosions, 
and bullets must live in this same place 


along with your program code. It’s a tight fit. 


recently-released specifications for the 
Sony Playstation 2 reveal that the sys- 
tem will have 32MB of main memory. 
But since it’s currently in development, 
that might change.) In other words, 
the PC has a huge leg up on consoles as 
far as main memory goes and it doesn’t 
look as if that will end anytime soon. 
Keeping these restrictions in mind 
when developing a game is critically 
important, especially if you want to do 
simultaneous PC/console development 
(or worse yet, if you decide partially 
through your PC development to try 
porting it to a console). Many of the 
newest PC games require 24 or 32MB 
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of loaded resources, so trying to fit 
that into a console is a daunting task. 
It’s comparable to trying to fit an ele- 
phant into a Volkswagen. And don’t 
expect consoles ever to catch up. PCs 
and consoles both use the same mem- 
ory components and therefore on- 
board memory sizes for each are 
increasing at the same rate of approxi- 
mately four times every three years. As 
long as PCs cost many times more 
than consoles, they will always have 
more memory. 

So, you have a game that barely fits 
onto a PC, and then the producer starts 
talking about porting to a console. 
What do you do? Well, it’s an old story 
in game development: A group of pro- 
grammers just start building a game 
and before they know it, they’re at 
SOMB of resources with no idea how 
they got there. Then they end up 
spending many man-months trying to 
shrink the game to fit on a consumer 
PC. At that stage, the idea to port the 
game to a console has to remain exact- 
ly that — an idea. You could never get 
it on a Playstation at that stage. 

It’s all too easy to allow this scenario 
to occur because most game program- 
mers use systems with at least 128MB 
of memory, and many games can go 
well into their second half of develop- 
ment without anyone ever seriously 
looking at their memory footprint. 
Code, much like a gas, expands in vol- 
ume to fill its container. Therefore it’s 
up to the responsible programmer to 
set a clear goal for the size of the code 
base, know where it’s going, and make 
sure that it stays on course. The basic 
ideas about memory management that 
I will explore are ones common to con- 
soles and PCs. It’s just more important 
to consider them while producing on a 
console game because the environment 
is so restrictive. Let’s begin by looking 
at some useful coding techniques. 


Memory Pools 


See data in a computer game con- 
sists of large numbers of com- 
mon data types. Examples of this are 
the monsters in your world, bullets fly- 
ing around them, polygons that make 
them up, the execute buffers that ren- 
der them, and so on. You need to 
maintain lists of these data structures 
so they can be accessed quickly and 
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efficiently. A good 
way to handle this 
data is with a mem- 
ory pool manager. 
A memory pool 
manager is a piece 
of code that han- 
dles large collec- 
tions of dynamical- 
ly created data of a 
common type. 
With this layer of 
code, we can han- 
dle the allocation, 
de-allocation, and 
usage of these data 
elements. We can 
also keep track of 
important statistics 
about the data such 
as the greatest 
number of bullets that was ever in exis- 
tence at one time during an execution 
of the game. Knowing these statistics 
can be very helpful in setting maxi- 
mums that help compress your game’s 
footprint onto a given system. I divide 
my memory pools into two separate 
versions. The first is responsible for 
handling data types which cannot 
have a maximum number of elements 
forced onto them. However, they must 
share the common trait that they are 
always allocated and de-allocated in 
two independent stages. The second 
type of memory pool handles data 
types that have a limited number in 
existence at any given time, which 
lends itself well to a temporal caching 
system. 


Cyclic Memory Pools 


aL consider the first style of mem- 
ory pool. To give you a clear idea 
of what type of data elements fall into 
the above description of this pool, it’s 
any data list that is allocated element 
by element until it reaches its maxi- 
mum growth for that cycle and is then 
completely destroyed so the process 
can begin again. Many data types in 
games actually fall into this category, 
and most involve frame-specific data 
because the frame is a convenient 
cycle. Examples of this data type 
include Direct3D execute buffers, poly- 
gons generated from 3D clipping, 
spans for scanline hidden surface 
removal, and AI transversal lists; all of 
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Hungry common data types. These monsters’ polygons are 
part of a cyclic memory pool. 





which happen to be tied to the frame 
cycle. You build the data fresh every 
frame, and at the end of the frame you 
dispose of all that you created. Looking 
through a game’s code base will most 
likely reveal many more algorithms 
that use this type of data. 

One way to manage this data is to use 
a linked list that grows dynamically 
along with the data. This is easy but not 
very fast. First, you must call malloc (or 
new) for every element you create. For 
some data types this could easily be 
thousands of times per frame. But since 
these data elements need to be truly 
dynamic, a pre-allocated array will not 
work. Therefore, combining these two 
choices into a hybrid is what is called 
for. This is the first type of memory 
pool. 

This memory pool allocates large 
numbers of elements with a single call 
to malloc. As new elements are needed, 
the memory pool system hands out 
pointers to memory blocks that have 
already been allocated as part of a previ- 
ous chunk. If you run out, the memory 
pool will allocate another large block of 
elements for the next n requests for new 
elements. This keeps the number of sys- 
tem-level allocations to a minimum. 


The trick is maintaining the balance 
between saving time by creating more 


elements with each real allocation and 
losing memory with allocated space that 
goes unused. Each type of data element 
will probably work best with its own 


block size, which is determined by 


examining the data type’s usage during 
an average game. 


GAME DEVELOPER 











To reach this balance, you can cus- 
tomize the memory pool so that it 
grows and shrinks intelligently. For 
instance, if the data type tends to allo- 
cate the same number of elements 
every cycle, then there is no need to 
de-allocate the space every frame — 
just empty it and use it again. This 
results in even fewer system-level 
memory allocations. If the data type 
tends to spike up every few seconds, 
you can have the memory pool 
“prune” itself back to the average num- 
ber of elements per cycle, thereby using 
far less memory. 


Caching Memory Pools 


he secondary form of memory 

pools manage data elements that 
are dynamic and cannot be allocated 
and de-allocated in two independent 
stages. Although this describes nearly 
every type of data list, there is one 
other restriction that this pool places 
on data types. The data must be able to 
handle an arbitrary maximum of ele- 
ments to be enforced when a new ele- 
ment is requested. This memory pool is 
useful for “eye candy” — data elements 
such as bullets, explosions, and particle 
effects. Because console memory 
resources are very limited, wasting 
space on hundreds of bloody chunks is 
just not good. Therefore, a memory 
pool that keeps usage under control 
can be very helpful. Basically, this 
memory pool is a caching system. But 
many programmers only seem to use 
caches in reference to textures, when 
in fact they can be very useful 
with any number of data types. 

Let’s look at an example of 

what happens in my latest game, 
STAR TREK: HIDDEN EVIL. When an 
enemy drone is destroyed by a 
phaser blast, an explosion sprite 
is generated, a couple of smoke 
puffs are released, and a dozen 
spark particles are emitted. First, 
you don’t want to allocate and 
delete every one of these ele- 
ments each time a drone is 
destroyed. Take a quick look at 
some hyperactive console games 
and you can see that hundreds 
of these eye-candy objects are 
created every second. A good 
solution to this problem is to 
create a set number of each type 
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of data element, say 100 debris parti- 
cles, 30 smoke puffs, and so on, and 
then allow the memory pool to hand 
out new elements whenever they are 
needed without ever going over the set 
limit. This means that no system-level 
memory management occurs, which 
speeds up our code. We also know 
exactly how much memory each type 
of data takes up throughout the game. 

What happens when we run out of 
elements of a given type? A simple age- 
based caching system can be used to 
destroy old instances in favor of new 
ones. While this could conceivably 
degrade image quality or even game 
play, it will usually go completely 
unnoticed if you carefully balance 
resource savings vs. game-play costs. An 
old bullet that has been flying for three 
seconds and still hasn’t hit anything 
(such as one flying towards the sky) is 
probably not going to be missed if it 
disappears unnaturally. Smoke puffs 
and debris particles are also not going 
to be missed if they disappear a little 
too soon, especially since the player is 
most likely focusing on the area where 
new particles are being generated. 


Memory Pools Integration 


he integration of these pools into 

our code base should be simple 
enough since they are a very general 
class. For example, I wrote a cyclic 
memory pool type recently for han- 
dling dirty scanline updating in STAR 
TREK: HIDDEN EVIL. I had thousands of 
data elements, each of which repre- 


Ensign Sovak is demonstrating caching memory pools 
by destroying an enemy drone. Sparks are great can- 
didates for caching pools. 
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sented a region on a scanline that 
needed to be refreshed. I created a 
memory pool of these data elements to 
request from when I needed them. 
Since I had multiple dirty scanline 
screens working simultaneously, | 
ended up saving tens of thousands of 
new and delete calls on peak frames. And 
by using very large chunks of a thou- 
sand data elements per pool, I had 
excellent cache locality coherency 
when walking the lists. 

The integration of the caching mem- 
ory pool might not be quite as obvious. 
All data elements that belong to these 
types of pools must derive from a com- 
mon class. This common class contains 
one item: the field on which to base 
the caching algorithm. Earlier in the 
article, | implied that this caching 
scheme had to be based on the age of 
the object, but it can really be based on 
anything. Any heuristic that deter- 
mines which element in the pool 
should be expunged in favor of a new 
element will do. Once you have all 
data elements deriving from the base 
class, the rest of the integration is the 
same as the other memory pool. Just 
stop allocating and deleting elements 
and instead request them from the 
appropriate memory pool system. 

Once most objects in our game are 
based on the memory pool classes, we 
can expand their usefulness by turning 
them into statistic recorders to monitor 
memory use. Pools can keep track of 
how many of a given data element 
have been allocated, how many have 
been used, measure the peaks, and 
determine the averages. All this infor- 
mation can be gathered easily by 
the memory pool system and 
easily retrieved to help reduce 
your game’s memory footprint. 
This data is also very useful for 
customizing the actions of each 
memory pool used by your 
game. For instance, you might 
find that you are requesting sig- 
nificantly more bullets per sec- 
ond than you first guessed and 
it’s causing them to expire too 
early. Therefore, you raise your 
allowance for bullets. 

An example of the real-world 
usefulness of these statistics can 
be seen in our memory reduction 
work on BENEATH. Our memory 
footprint was much too large at 
the end of the project, so we sent 
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one of our programmers 
into the code to determine 
where we could cut. By 
breaking the memory usage 
down to the object level, we 
saw a tall spike at the data 
object “flare shards.” Flare 
shards are pieces that fly off 
when a flare object 
explodes in the game. (A 
flare is shot from a flare 
gun, an object that many 
creatures use.) We discov- 
ered that the spike was 
caused by the fact that mul- 
tiple creatures had flare 
guns, each flare gun had a 
pre-allocated clip of ten 
flares, and each flare had a pre-allocat- 
ed clip of twelve flare shards. The result 
was thousands of flare shards just sit- 
ting in memory waiting to be used. 

Our solution was to create a flare 
shard pool in which we allocated a set 
number of flare shards at the beginning 
of the game. Then, whenever a new 
flare shard was needed, it requested 
one from a memory pool. If the memo- 
ry pool was full, the oldest flare shard 
was retired early and became the new 
flare shard. We ended up saving 
megabytes of data space. Something 
that small had actually gone unnoticed 
by us. 


Memory Manager 


A any experienced programmer 
can attest, memory errors can be 


some of the most difficult bugs to track 
down. And when you consider that 
consoles are often weak in terms of 
development tools, having your own 
code to help track down memory bugs 
can be quite a time saver. This is where 
a memory manager can be useful (see 
Figure 1). Normally, programs use the 
standard malloc and free (or their C++ 
equivalents, new and delete) when deal- 
ing with memory allocation; however, 
these functions do not help us track 
down memory leaks, prevent us from 
overwriting our memory bounds, or 
handle other common memory errors. 
So, let’s look at a simple layer that we 
Can wrap around new and delete in order 
to help us debug our code. 

Let’s examine how this layer will 
work. The meat of the code marks each 
memory allocation with a header and 


Cyclic Memory Pool 


FIGURE 1. 


Our memory manager's block structure. 





trailer containing very specific data 
that allows us to track the blocks. In 
the header we place a pointer to the 
source code file-name string that the 
block was allocated in and the line 
number it was allocated on. This lets us 
identify memory errors by generating 
useful debugging messages that lead 
the programmer straight to the prob- 
lem. We also include a marker in both 
the header and trailer that allows us to 
track its current state and watch for 
boundary overwrites. 

When an allocation occurs, our cus- 
tom routine allocates memory using a 
malloc call with enough additional space 
to hold the header and trailer. The data 
portion of the block is cleared out to an 
uninitialized value. The header and 
trailer are initialized correctly with the 
file name, line number, and overwrite 
markers. This memory block is then 
put into a hash table to give us better 
searching performance when we need 
to find blocks in later stages, such as 
validation or freeing. The memory 
block is then returned with the appro- 
priate adjustment for the header and 
the rest of the program is none the 
wiser that this has taken place behind 
the scenes. 

Let’s look at what happens when we 
free memory. First, check to see if the 
memory block has already been freed 
by looking at its header state. Also 
check the header and trailer markers to 
see if an unrecognized value has been 
placed there, implying that a boundary 
overwrite has occurred. This does not 
catch all memory overwrites because 
obviously the overwrite could have 
written our marker, and it would 
appear untouched. However, in all my 
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Memory Management 
Block Structure 


years of using memory man- 
agers such as this, I’ve never 
seen that happen. If this 

_ memory block passes these 
initial tests, we make sure 
that the block is in our hash 
table. If we find it, then we 
have a legitimate free on a 
legitimate block. We free the 
data block by marking it as 
freed in its header state and 
then filling the block with a 
“freed value.” The memory 
block is then removed from 
our hash table and we finally 
call free() to actually free the 
block on a system level. 

Using these two functions, 
we can catch many memory errors 
when they are first introduced and not 
weeks later when we’re trying to track 
down some very obscure, difficult-to- 
reproduce bug. We can also use these 
functions to track our total memory 
allocation, peak memory allocation, 
average memory allocation, and other 
useful code statistics. 

Finding memory leaks is another big 
advantage to this code layer. At the 
end of your program, you can call the 
FindMemoryLeaks() function to find all 
memory leaks. The code to handle this 
is quite simple. By the time you call 
this function, a free should have been 
called for every malloc you made; there- 
fore, any memory blocks that still exist 
in the hash table are memory leaks. 
Just walk the table, printing out every 
block along with its file name and line 
number information. You now have a 
printed list of every memory leak in 
your game. 

With this layer written, how do we 
integrate this system into our code 
base? We could overload new and delete, 
or we could replace all our standard C 
memory calls with our own personal 
functions if we didn’t want to use C++. 
The path I usually take is to use 
defines, such as this: 

#ifdef _DEBUG 
#define Allocate(x) \ 

Memor yManager->Allocate(__FILE 
#define Deallocate(x) \ 

Memor yManager->Deallocate(x) 
#else 
#define Allocate(x) malloc(x) 
#define Deallocate(x) free(x) 
#endif 

This method keeps you from having 
to type the file and line parameters for 


LINE__,x) 


—— 9 -— 
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every allocate function call. Also 
notice that the entire memory 
manager layer is skipped when 
not in a debug build, thereby 
speeding up the code base in the 
final release build. (And by that 
time, all the memory bugs should 
be gone, right?) 


Resource Wrapping 


he memory manager that we 

just looked at should save 
time when tracking down memo- 
ry bugs. But what is the code real- 
ly all about? It is just wrapper 
code; a custom high-level library 
that encloses a low-level library, such 
as the C memory manager, which pro- 
vides improved functionality. By mak- 
ing sure that our wrapper is the only 
entry into the system, we can receive 
customized records that the low-level 
system was never designed to give. 

Let’s take this idea of the wrapper 
even further. There are many other 
resources that we can surround with 
wrappers. Why not wrap the file IO sys- 
tem? Or write a custom library instead 
of using fopen() and fclose()? This layer 
can be used to abstract packed files 
(many files merged into one for faster 
disk access) or keep endian switching 
straight between Macs, PCs, and con- 
soles. You can also use it to track down 
unclosed files that can cause quite a bit 
of trouble, as a recent incident at Presto 
showed us. 

Windows gives each application a 
maximum number of file handles, 
which when used up, can no longer be 
opened using standard C file access 
conventions. If you’re opening files 
without closing them, you eventually 
use up these file handles and run out. A 
recent bug in our load/save system on 
STAR TREK ended up being a section of 
code that was not closing its files, and 
after five or six mission loads, we 
would run out of handles. We wasted a 
considerable amount of time on a bug 
that could have easily been avoided 
with a wrapper library reporting 
unclosed files. That’s what wrapping 
systems are all about — adding more 
functionality to already-written 
systems. 

Another benefit of writing wrapper 
code is that it helps us achieve our 
overall goal: porting between multiple 
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Jack confronts his arachnophobia to squash bugs. Of 
course, our memory manager can do that for him. 





platforms. By maintaining a custom 
application interface to a system, you 
avoid having to rewrite code through- 
out a project, and instead update only 
one library. For instance, if you had a 
game that used Windows-specific timer 
devices, you would have to track down 
all instances of such timer devices 
throughout your code base when port- 
ing to a console. Instead, write a wrap- 
per class around the device that’s used 
by the entire code base. Then, when 
it’s time to port your game to another 
platform, you only have to touch one 
file by rewriting the timer wrapper. All 
other code in the game remains the 
same because it all uses your custom 
timer interface. 


Specific Porting Issues 


io take a moment to think about 
some specific issues when porting 
from a PC to a console. First, when 
developing for a console (especially a 
new console for which the develop- 
ment environments are not mature), 
you're often developing with DOS- 
prompt linkers and no support pro- 
grams outside a basic C compiler. 

So when doing a port, take advantage 
of the PC’s enormous library of devel- 
opment support before actually mov- 
ing the code to the new platform. 

For instance, using NuMega’s Bounds- 
Checker is good place to start. For 
those who have never used it, 
BoundsChecker helps programmers 
find memory bugs similar to those dis- 
cussed above, such as double frees, 
overwriting boundaries, and memory 
leaks. This program can help you 
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remove memory errors before 
you even move the code base 
over to the console. 

Another issue to think about is 
the difference between the 
Windows operating system and 
whatever operating system exists 
on the console you are porting 
to. (Or lack of operating system, 
as the case may be.) Windows is 
significantly more complex than 
anything you'll find on a con- 
sole. (With the obvious excep- 
tion of the Sega Dreamcast, 
which has Windows CE, but 
even that is a very stripped-down 
version of what you use every 
day on a PC.) As with all 
advanced operating systems, Windows 
can be quite forgiving of mistakes — 
sometimes too forgiving. Because if 
you make a mistake that Windows can 
survive, chances are your console 
won't. For instance, I’ve seen program- 
mers not clean up after their memory 
allocation because they know that 
when they shut down their program, 
Windows will clean up their memory 
space. This is a horrible habit to get 
into, but from my experience, it seems 
common. Always work off the assump- 
tion that you do not have a safety net. 
When you type a new, match it with a 
delete immediately. When you open a 
file, make sure that you close it. 

Other issues to consider, which I do 
not have the space to get into here, are 
problems associated with other 
resources, such as video space. Just as 
PCs will always have more main mem- 
ory than consoles, they will also 
always have more video memory, 
because PCs owners are willing to 
spend more. The same problem exists 
for sound memory. Consoles don’t yet 
have hard drives for high-speed data 
spooling or massive state saves, and 
the CD-ROMs they do have are usually 
considerably slower than what is com- 
mon on PCs. In short, consoles are 
amazingly limited compared to PCs. 
But if you know what you're doing, 
you can make a game that’s just as 
incredible as anything on a PC — 
sometimes even more so. 
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Irrational Games’ 
SYSTEM SHOCK 2 


By Jonathan Chey 










his is the story of a young and inexperienced 


company that was given the chance to develop 





the sequel to one of the top ten games of all time. The 
sequel was allotted roughly one year of development with 
its full team. To make up for the short development cycle 
and correspondingly small budget, the project was sup- 
posed to reuse technology. Not technology in the sense of a stand-alone 
engine from another game, but individual components that were spun 
off from yet another game, THIEF: THE DARK PROJECT. The THIEF technol- 
ogy was still under development and months away from completion 
when our team started working with it. To cap everything off, the pro- 
ject was a collaborative effort between two companies based on a con- 


tract that only loosely defined the responsibilities of each organization. 








_ Jonathan Chey was the project manager and a programmer on SYSTEM SHOCK 2. He is also one of the co- 

_ founders of Irrational Games. Prior to founding Irrational Games, he worked at Looking Glass Studios and 
_ prior to that he received his Ph.D. in Cognitive Science from Boston University. He is currently working on 
his tan back in his hometown of Sydney, Australia. He can be reached at jon@irrational-games.com. 
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Add to these gloomy initial conditions 
the fact that the game from which our 
shared technology was derived slipped more 
than six months from the initially estimated 
date, that several developers quit during the 
project, that we didn’t bring the full team 
up to strength until six months from the 
final ship date, and that we struggled with 
financial and business problems during the 
entire project. Having learned this, you 
might anticipate the worst. Strangely, 
SYSTEM SHOCK 2 shipped within two months 
of its targeted date and will, I hope, be rec- 
ognized as a sequel worthy of its esteemed 
ancestor. 


Let’s step back and trace the origins of the The team at Irrational Games, from left to right: First row: Steve Kimura/Artist, 


companies and the project. Looking Glass Jonathan Chey/Project Director, Justin Waks/Multiplayer Programmer, 
Studios is familiar to many as the creator of a [OMI aa at ea) ee CL] Ma LPL MeL dL 
series of highly innovative titles including Hart/Designer, Lulu Lamer/QA Lead. Second row: lan Vogel/Level Designer, 
the original SYSTEM SHOCK, the ULTIMA Scott Blinn/Level Designer, Michael Swiderek/Artist, Rob Caminos/Motion 
UNDERWORLD series, the FLIGHT UNLIMITED Editor, Nate Wells/Artist. Third row: Mike Ryan/Level Designer, Ken 

line and TERRA NOvA, among others. Three Levine/Lead Designer, Mathias Boynton/Level Designer. Not shown: Gareth 


years ago, Ken Levine, Rob Fermier and | Hinds/Lead Artist. 
were developers at Looking Glass, struggling 
with the aftermath of VOYAGER, an aborted 
Star Trek: Voyager-licensed project. At the time, Looking Glass It’s the Engine, Stupid 
was in financial and creative disarray after a series of titles 














that, though critically acclaimed, had failed to meet sales ~ othing impacted the development of SYSTEM SHOCK as 
expectations, the latest being TERRA NOVA and BRITISH OPEN much as the existing technology we got from Looking 
CHAMPIONSHIP GOLF. Frustration with the 18 months wasted Glass. This fact cannot be classified monolithically under the 
on VOYAGER and a certain amount of hubris prompted three heading of “what went wrong” or “what went right,” how- 
of us to strike out on our own to test our game design and ever, because it went both wrong and right. The technology 
management ideas. We wanted to nail down a rigorous and we used was the so-called “Dark Engine,” which was essen- 
technologically feasible design, focus on game play, and force _ tially technology developed as a result of Looking Glass’s 
ourselves to make decisions rather than allow ourselves to THIEF: THE DARK PROJECT (for more about its development, 


stagnate in indecision. We wanted to run a project. 

So we formed Irrational Games. After some misadventures SYSTEM SHOCK 2 
with other development contracts, we unexpectedly found 
ourselves back at work with Looking Glass as a company 
rather than as employees. Initially, our brief was to prepare a 
prototype based on the still-in-development THIEF technology 
recast as a science-fiction game. The scope of the project was 
very wide, but we quickly decided to follow in the footsteps of 
the original SYSTEM SHOCK. Our initial design problem was 
how to construct such a game without the luxury of the actu- 
al SYSTEM SHOCK license, since no publisher had yet been 
signed. 

Our initial prototype was developed by the three of us 
working with a series of contract artists. Our focus was on 
the core game-play elements: an object-rich world contain- 
ing lots of interactive items, a story conveyed through 
recorded logs (not interaction with living NPCs), and game 
play realized through simple, reusable elements. This focus 
enticed Electronic Arts into signing on as our publisher early 
in 1998 — a fantastic break for us. It meant we could now 
utilize the real SYSTEM SHOCK name and characters. 

Immediately, we went back to our original design, threw 
away some of the crazier ideas that had been percolating and 
began integrating more of the rich SYSTEM SHOCK universe 
into the title. That was the point at which the real develop- 
ment began. 


Irrational Games LLC 

Cambridge, Mass. 
(617) 441-6333 

nti) (Www. itrational-zames.cam 

Looking Glass Studios Inc. 
Cambridge, Mass. 

(617) 441-6333 

hito://www.iglass.cam 

Release date: August 1999 

Intended platform: Windows 95/98 

Project budget: $1.7 million 

Project length: 18 months 

Team size: 15 full-time developers, 10-15 part-time developers 

Critical development hardware: Pentium || machines, 200MHz 
to 450MHz with 64MB to 128MB RAM, Nvidia Riva 128, 
Voodoo, Voodoo 2, TNT cards, Creative Labs’ sound cards, 
Wacom tablets, Windows 95/98. Also used SGI Indigo work- 
Stations. 

Critical development software: Microsoft Visual C++ 5.0, Opus 
Make, 3D Studio Max, Adobe Photoshop, Alias!Wavefront 
Power Animator, DeBabelizer Pro, RCS, Filemaker Pro, and 
Adaptive Optics motion capture software 
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see “Looking Glass’s THIEF: THE DARK 
PROJECT,” Postmortem, July 1999), 

The THIEF technology was developed 
with an eye toward reuse, and I will 
refer to it in this article as an “engine.” 
However, it is not an engine in the 
Same sense aS QUAKE’S, UNREAL’S, and 
LithTech. The Dark Engine was never 
delivered to the SYSTEM SHOCK team as 
a finished piece of code, nor were 
we ever presented with a final set 
of APIs that the engine was to 
implement. Instead, we worked 
with the same code base as the 
THIEF team for most of the project 
(excluding a brief window of time 
when we made a copy of the 
source code while the THIEF team 
prepared to ship the game). 
Remarkably, it is still possible to 
compile a hybrid executable out of this 
tree that can play both THIEF and 
SYSTEM SHOCK 2 based on a variable in a 
configuration file. 

This intimate sharing of code both 
helped and hurt us. We had direct 
access to the ongoing bug-fixes and 
engine enhancements flowing from the 
THIEF team. It exposed us to bugs that 
the THIEF team introduced, but it also 
gave us the ability to fix bugs and add 
new features to the engine. Because we 
had this power, we were sometimes 
expected to fix engine problems our- 
selves rather than turning them over to 
Looking Glass programmers, which 
wasn’t always to our benefit. At times 
we longed for a finished and frozen 
engine with an unalterable API that 
was rigidly defined and implemented 
— the perfect black box. But being able 
to tamper with the engine allowed us 
to change it to support SYSTEM 
SHOCK-specific features in ways that a 
general engine never could. 


What Went Right 


THE IRRATIONAL DEVELOPMENT MODEL. 
@ In our hubris after leaving 

Looking Glass, we formulated several 
informal approaches to development 
that we intended to test out on our 
projects. Most of these approaches 
proved to be successful and, I think, 
formed the basis of our ability to com- 
plete the project to our satisfaction. 

First, we designed to our technology 
rather than building technology to fit 
our design. Under this model, we first 
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analyzed our technological capabilities 
and then decided on a design that 
would work with it. This process is 
almost mandatory when reusing an 
engine. Sometimes it can be difficult to 
stick with this when a great design idea 
doesn’t fit the technology, but we 
applied the principal pretty ruthlessly. 
And many of the times we did deviate 
we had problems. 

Another feature of our development 
philosophy is that everyone partici- 
pates in game design. Why? Because all 
three of the Irrational founders wanted 
to set the design direction of our prod- 
ucts, programmers were able to resolve 
design issues without having to stick to 
a design spec, and we strongly empha- 
sized game design skills when hiring all 
of our employees and contractors. In 
all our interviews, one of our most 
pressing questions to ourselves was 
“Does this person get games?” Failure 
to “get” them was a definite strike 
against any prospective employee. 
Ultimately, the team’s passion for and 
understanding of games was a major 
contributor to the design of the final 
product. 

The final goal of our development 
process was to make decisions and hit 
deadlines. We focused on moving for- 
ward, and we didn’t allow ourselves to 
be bogged down. We desperately want- 
ed to ship a game and believed that the 
discipline imposed by the rule of for- 
ward motion would ultimately pay off 
in terms of the final product quality as 
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well as delivery date. While there are 
features in SYSTEM SHOCK 2 that could 
have been better if we had not rushed 
them (the character portraits for exam- 
ple), we still firmly believe that the 
game as a whole was made better by 
our resolve to finish it on time. 

USE OF SIMPLE, REUSABLE GAME-PLAY 
@ eELemeNTS. The field of compa- 
nies developing first-person shooters 
like id and Valve, among others, is 
impressive. From the outset we realized 
that we would have to work smarter, 
not harder, to make a game that could 
stand up in this market. It would be a 
futile attempt to create scarier mon- 
sters, bigger guns, or higher-polygon 
environments. Additionally, we real- 
ized that our design time and budget 
were very tight and that we would not 
have time to carefully hand-script com- 
plicated game-play sequences in the 
engine. Instead, in an attempt to shift 
the battlefield, we chose to focus on 
simple, reusable game-play elements. 
The success of HALF-LIFE, which 
launched while we were in the middle 
of SYSTEM SHOCK 2 confirmed our intu- 
itions in this respect. We simply didn’t 
have the time, resources or technology 
to develop the scripted cinematic 
sequences used by HALF-LIFE. We con- 
soled ourselves with the knowledge 
that we were not even trying to do so. 

This strategy melded very well with 
our acquisition of the SYSTEM SHOCK 
license, as the original SYSTEM SHOCK 
had already been down this road. We 
decided to expand on elements that we 
liked in SYSTEM SHOCK and then add 
similar new systems. Each such new 
system was evaluated rigorously in 
terms of game-play benefits, underly- 
ing technology, and design-time 
requirements. 

For example, take the ship’s security 
system. Early on we decided that we 
wanted to continue the surveillance 
theme from SYSTEM SHOCK, which we 
could leverage throughout the game to 
provide lots of game play for very little 
implementation cost. We realized that 
security cameras would be trivial to 
implement using existing AI systems 
(they are just Als pruned of many of 
their normal abilities) and that once 
we had cameras that could spot and 
track the player, we would be able to 
build several game-play elements out 
of them. Cameras could summon mon- 
sters to the player, so much of the 
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game play consisted of avoiding detec- 
tion by security cameras and destroy- 
ing cameras before you were seen. 
Because cameras scan fixed arcs, the 
player can utilize timing to sneak by 
cameras, pop out and shoot them at 
the right moment, or get underneath 
them and bash them with a melee 
weapon. Once a player is spotted, mon- 
sters flood the area until the player is 
able to shut off the security system 
somehow or the system times out. This 
introduces the need to deactivate secu- 
rity systems via security computers that 
are scattered throughout the level. 

This type of system was technologi- 
cally simple to implement and required 
minimal design effort. While not com- 
pletely formulaic, the basic procedure 
to set up a camera and security system 
could be shown to designers quickly 
using a few simple rules. From this one 
system and a couple of associated sub- 
systems, we derived a large amount of 
game play without having designers 
create and implement complicated 
scripted sequences and story elements. 
When you throw together many such 
systems (as we did), you end up with a 
lot of game play. 

COOPERATIVE DEVELOPMENT. SYSTEM 

@ SHOCK 2 was truly a cooperative 
development between Irrational and 
Looking Glass. Looking Glass provided 
the engine and a lot of infrastructure 
support (such as quality assurance), 
while Irrational handled the design, 
project leadership, and the responsibil- 
ity for marshaling resources into the 
final product. Both entities 
contributed personnel to the 
development team. 
Inevitably, some friction 
arose from this process while 
we sorted out who was 
responsible for what. 
However, this cooperation 
was ultimately successful 
because both sides were inter- 
ested in developing a great 
product, and we were able to 
compromise on most issues. 
(On the most mundane level, 
Irrational ended up providing 
late-night, weekend meals for 
its development team and for 
Looking Glass on some days 
during the week.) 

Our cooperative arrange- 
ment was founded on a con- 
tractual agreement, but we 
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avoided falling back on this contract in 
most cases. We preferred to resolve 
issues through informal discussions. 
Conceptually, Irrational was to be 
responsible for the development of the 
product and Looking Glass was to pro- 
vide A/V content and quality assurance 
Services. 

During the early stages of the pro- 
ject, a deal was worked out whereby a 
small number of Looking Glass person- 
nel were subcontracted to Irrational 
when it was determined that 
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Irrational’s development budget could 
not cover all the SYSTEM SHOCK 2 devel- 
opment costs, and as compensation for 
the late delivery of the THIEF technolo- 
gy. Unfortunately, these personnel 
were not always available on time — a 
situation which caused us much con- 
cern. We knew that this “resource 
debt” could never really be paid off 
until THIEF shipped — nothing is so dif- 
ficult as prying resources away from a 
team that is trying to ship a product 
before Christmas. It wasn’t until 
December 1998 that we first began to 
see some of these promised resources. 
However, these “resources” — real peo- 
ple — had just finished up THIEF and 
were totally fried following the gruel- 
ing crunch to ship THIEF. The saving 
grace and reason that this arrangement 
was ultimately successful was that 
these developers were all talented and 
experienced and already knew the 
technology. Their addition to the team 
gave us a Solid boost during the final 
months in our ship cycle. 

The other benefit of the cooperative 
development agreement between 
Irrational and Looking Glass was that 
our respective engine programmers 
could share knowledge. The ability to 
walk over and quiz engine program- 
mers about systems proved to be an 
invaluable benefit that more than com- 
pensated for the lack of a rigorously 
specified and documented engine. 
Without a formal understanding of the 
engine, we had to resolve engine issues 
in a personal and informal manner. 
This process relied on the 
personalities of the respon- 
sible individuals on the 
engine team. Thus, the 
Irrational programmers bal- 
anced their time not only 
according to the complexity 
of their tasks but also 
according to how much 
support was available from 
the engine side. 

Overall, Irrational’s rela- 
tionship with Looking Glass 
was an unusually close one 
and ultimately successful as 
a result of our mutual 
respect and willingness to 
work with each other. 
Despite our partnership 
being based on a formal 
contractual arrangement, it 
was our ability to work flex- 
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ibly above this legal level that 
enabled the development to 
proceed smoothly. 

DESIGN LESSONS FROM 
@ System SHock. Though 
the SYSTEM SHOCK license was 
wonderful, there were some 
problems. The biggest was sim- 
ply the challenge of living up to 
the original. Fortunately, we 
had the freedom to pay homage 
to SYSTEM SHOCK legitimately by 
reusing elements from it. 
Additionally, we had access to 
some of the original developers, 
including our own lead pro- 
grammer Rob Fermier. 

As with most sequels, we 
faced the challenge of keeping 
the good elements of the original 
game while not blindly copying them. 
We knew that most players would 
want a new story set in the same 
world, with the same basic flavor as 
the original game, yet we also wanted 
to reach out to a broader audience. We 
resolved these issues by identifying the 
key elements that made SYSTEM SHOCK 
so good and reinterpreting those ele- 
ments using current technology. Some 
elements made it through largely 
unchanged (for example, the story- 
telling logs and e-mails, the tiber vil- 
lain Shodan and her close involve- 
ment with the player throughout the 
game, and the complexity of the 
world). Other elements were reinter- 
preted (such as the look of the envi- 
ronment, player interface, and tech- 
niques for interacting with the world). 
A small number of items were simply 
cut, most notably the cyberspace 
sequences — we were fairly united in 
our opinion that these just didn’t work 
well in the original. 

Notably, as with the original SySTEM 
SHOCK, we opted to omit interactive 
NPCs in the game. SYSTEM SHOCK 
eschewed living NPCs because the 
technology of the day was simply inad- 
equate to support believable and enjoy- 
able interactions with them. It’s been 
four years, and that technology is still 
not available. So we continued the tra- 
dition of SysTEM SHOCK and provided 
players with background information 
using personal logs and e-mails gleaned 
from the bodies of dead NPCs. 

Perhaps our biggest deviation from 
the original revolved around the play- 
er interface. It’s commonly accepted 
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that SYSTEM SHOCK’s interface, while 
elegant and powerful once under- 
stood, presented a significant barrier to 
entry. Our primary goal was to simpli- 
fy this interface without dumbing it 
down. We devoted more design effort 
to this task than to any other system 
in the game, and it required many iter- 
ations before we were happy with it. 
We adopted a bi-modal interface in 
which there are two distinct modes 
(inventory management and 
combat/exploration) between which 
the player can toggle. This was a risky 
decision. This bi-modal model was 
mandated by our desire to keep the 
familiar and powerful mouse-look 
metaphor common to first-person 
shooters while retaining cursor-based 
inventory management. How we 
switched between modes became our 
biggest design challenge. Sometimes 
these mode changes are explicitly 
requested through a mode change key, 
and sometimes they are invoked auto- 
matically by attempting to pick up an 
object in the world. So far this system 
seems to be working well, though only 
time and user feedback will tell 
whether we really got it right. 
WORKING WITH A YOUNG TEAM. The 

@ SysTEM SHOCK team was fright- 
eningly young and inexperienced, 
especially for such a high-profile title. 
Many of our team members were new 
to the industry or had only a few 
months’ experience, including the 
majority of artists and all the level 
builders. Of the three principals, only 
Rob had previous experience in his role 
as lead programmer. Neither Ken, the 
lead designer, nor I, the project manag- 
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er, had previously worked in 
these roles. 

It’s not totally clear how 
we pulled off our project 
with our limited experience. 
Partially, it must have been 
due to our ability to bond as 
a team and share knowledge 
in our communal work envi- 
ronment (“the pit”). To a cer- 
tain extent, inexperience also 
bred enthusiasm and com- 
mitment that might not have 
been present with a more 
jaded set of developers. We 
also worked hard to transfer 
knowledge from the more 
experienced developers to 
the less seasoned individuals. 
Rob worked on an extremely compre- 
hensive set of documentation for the 
functional object tools, as well as a set 
of exercises (“object school”) to be 
worked on each week. These kinds of 
efforts paid back their investment 
many times over. 

This is not to say that our progress 
was all sweetness and light. The art 
team, for example, floundered for a 
long time as we tried to integrate the 
junior artists and imbue a common art 
look in the team’s psyche. We had a lot 
of very mediocre art midway through 
our project and the art team was stag- 
nating. Ultimately, management had 
little to do with the art team’s success 
— they were largely able to organize 
themselves and create a solid, original 
look. 

On the management front, our inex- 
perience was apparent. We blundered 
through the early stages of develop- 
ment with scheduling and manage- 
ment issues. A large problem was our 
failure to assign specific areas of 
responsibility and authority early on. 
Bad feelings arose as a result, which 
could have been avoided if we had 
clearly delineated areas of responsibili- 
ty from the start. 


What Went Wrong 


POOR LEVEL DESIGN PROCESS. Level 
@ design is a clearly defined pro- 
fessional activity in the game industry. 
It’s a profession that mixes artistic and 
technical skills in equal measure, and 
the bar is raised on both fronts every 
year. Despite our understanding from 
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the very beginning that the 
level building would be a 
problematic part of the 
SYSTEM SHOCK development 
process, we didn’t quite 
grasp how difficult and time 
consuming it would be, nor 
did we expect that it would 
eventually block the ship- 
ment of the game. 

In hindsight, our failure 
to understand the amount 
of work needed to design 
levels is reprehensible given 
that we had seen the same 
problems emerge on THIEF, 
and that SYSTEM SHOCK 2 lev- 
els involved substantially 
more complex object place- 
ment than THIEF. I attribute this error 
mostly to our denial of the problem — 
we had a limited budget for level 
designers and there is a long training 
time required to get designers familiar 
with the complex Dark Editor. So we 
locked ourselves into working with the 
resources we had. Since each individ- 
ual task required from the designer 
(apart from initial architectural work) 
was relatively simple, it was easy to 
believe that the sum total of work was 
also relatively small. What we over- 
looked was the fact that SYSTEM SHOCK 
2 involves so many objects, scripts and 
parameters. As such, the work load on 
level designers was excessively large. In 
addition, we made a classic beginner’s 
mistake and failed to provide adequate 
time for tuning in response to play- 
testing feedback. In SYSTEM SHOCK 2 
this was particularly important 
because the ability of the player to re- 
enter levels means that the difficulty 
of a level cannot be adjusted in isola- 
tion from the rest of the game. Often 
we had to impose global changes 
across all levels, which could be very 
expensive even when the change was 
relatively minor. 

We took a novel approach to the 
level building process by attempting to 
apply design levels using a production- 
line method. Using this metaphor, we 
attempted to divorce the different 
stages of work on the level: rough 
architecture, decorative and functional 
objects, architectural polish, and light- 
ing. It was not considered necessary for 
the same individual to be involved in 
all stages of this production process. 
This approach had positive and nega- 
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tive consequences. The advantages 
were that we could track progress on 
levels, we could “bootstrap” levels fair- 
ly quickly, and we could (in theory) 
swap individuals in and out of differ- 
ent tasks. The disadvantages are fairly 
obvious, and most stem from the fact 
that the various stages of level design 
are clearly not independent (for exam- 
ple, architecture is ideally built with an 
understanding of the functional 
objects that are to be used in the level). 
Although I think our process was nec- 
essary in order to get the game out on 
time, it probably detracted from the 
quality of some of the levels. In addi- 
tion, psychological factors, such as lack 
of ownership and training issues (stem- 
ming from unfamiliarity with levels) 
speak very strongly against transferring 
people from one task or level to anoth- 
er. Nevertheless, there were several 
benefits of our procedure — mostly the 
ability to employ particularly talented 
individuals to pinch hit on particular 
levels, and the psychological benefits 
of completing architectural work early 
in, the schedule. 

Perhaps the rudest shock in our level 
building process came from our misun- 
derstanding of what part of the process 
would prove to be most difficult. 
Architectural work was actually fairly 
simple, because we intentionally kept 
our spaces fairly clean and did not 
attempt anything too unusual. 
However, placing and implementing 
our objects was far more complex and 
involved than we expected. One diffi- 
culty that we encountered was educat- 
ing our designers in what was expected 
from them in terms of game-play 
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implementation. Most of our 
level builders had previously 
built QUAKE or UNREAL levels 
and were not familiar with the 
style of game play that we 
were trying to build in SYSTEM 
SHOCK 2. Partially this was 
because we were simply 
exploring a style of game play 
that we did not entirely under- 
stand ourselves. But it reflect- 
ed a failure on our part to 
properly educate the design- 
ers. Building prototypical 
spaces, looking at past games 
and conducting more inten- 
sive discussions about game 
play will all be part of our 
future projects. 

Our other major design hurdle was 
the instability and inscrutability of 
Dromed, the Dark Engine editor. 
Dromed is a cantankerous beast and 
many man-months were spent strug- 
gling with its idiosyncrasies. Perhaps 
our biggest problem stemmed from the 
lack of support in one crucial area — 
the part of the engine concerned with 
translating the designer-placed brushes 
into the basic world representation. 
Like many complex 3D engines, the 
Dark Engine suffers from troubling 
epsilon issues (data errors caused by 
rounding inaccuracies) and other 
glitches that crop up during level com- 
pilation. Because the programmer who 
implemented the basic renderer and 
world representation was not available 
during the majority of the SYSTEM 
SHOCK 2 development cycle, we had to 
work around these problems. It was 
often a frustrating process when the 
fundamental cause of the problems was 
not even known. Over time we devel- 
oped a set of heuristics to avoid the 
majority of the glitches, but we were 
forced to lock down much of the level 
architecture before we wanted to in 
order to ensure stability. 

MOTION CAPTURE DIFFICULTIES. [he 

@ Dark Engine has a complex 
creature animation playback system 
and deformable mesh renderer. We 
encountered many problems with this 
piece of technology along our data 
integration path, and found quirks in 
the playback systems as well. Primarily, 
the system was hampered by the fact 
that data frequently had to be modified 
by hand, that mysterious bugs would 
appear in motions during playback 
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which had not been present in the 
source data, and that few tools were 
available for debugging and analysis. 
We were ill-equipped to deal with these 
kinds of problems, having devoted few 
resources to dealing with the technolo- 
gy problems. 

Our primary animation source was 
motion capture data. We were nervous 
about the technology from the start 
and attempted to minimize our risk by 
concentrating primarily on humanoid 
creatures with a small number of 
interesting variants such as spiders 
and floating boss monsters. In retro- 
spect, this was a very wise decision, as 
we had a lot of trouble even with this 
simple set of creatures. Motion cap- 
ture technology and capture services 
were contracted from a local compa- 
ny, but unfortunately this company 
viewed its motion capture work pri- 
marily as a side business and did not 
display much interest in it. In fact, 
they cancelled this sector of their 
business during our project, and we 
had to fight hard to complete the ses- 
sions that we had already scheduled 
with them. 

Our capture sessions were hampered 
by our inexperience with the technolo- 
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gy and by the fact that we did not plan 
properly for the sessions. We hadn’t 
defined key poses, rehearsed the 
motions, or ensured that our motions 
were compatible with the technology. 
Optical capture technology, the tech- 
nology that we used, can be glitchy 
and has difficulty with motions that 
have obscured markers, as in the death 
motions that were necessary for SYSTEM 
SHOCK 2. Over the course of three ses- 
sions, we gradually refined our 
motions, but we spent a lot of time 
reshooting failed captures from earlier 
sessions. 

Even in the best cases, most of our 
captures exhibit strange artifacts (feet 
pointing down through the ground, 
hands improperly aligned, and so on), 
whose causes are still unknown to us. 
In future projects we will hand-ani- 
mate almost all of the data, and we will 
need to understand better what aspect 
of the conversion process introduced 
these artifacts into our final game ani- 
mations, although the irregularities 
never appeared in our raw data. 
Motion capture technology, while 
highly efficient compared to hand ani- 
mation, must be approached carefully 
to obtain good results. 
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IMPLEMENTING SCRIPTED SEQUENCES. 
@ Motivated by the dramatic 
scripted sequences in HALF-LIFE, we 
attempted to introduce similar ele- 
ments into SYSTEM SHOCK 2. In doing 
so, we broke one of our rules: we tried 
to step outside the bounds of our tech- 
nology. Although we attempted rela- 
tively simple sequences and ultimately 
got them working, they were time 
sinks, and the payback was relatively 
slight. For example, we scripted a hal- 
lucinatory sequence in which the play- 
er character rides through the interior 
of the alien boss-monster, known as 
the Many. This so-called “Many ride” 
was the source of innumerable bugs — 
the player would be thrown off the 
moving platform, manage to kill his 
projected self, bump into walls, and so 
on. We confirmed our intuition that 
the Dark Engine does not support com- 
plex scripted sequences well because 
the toolset (AI, moving terrain, and 
animation) is not optimized for this 
sort of behavior. The moral is, once 
again, to work with your technology, 
not against it. 

INEXPERIENCE WITH MULTIPLAYER 
@ GAME DEVELOPMENT. Early in the 
project we were asked to identify the 
major risks associated with the project. 
Our number one candidate by far was 
the multiplayer component. This was 
the only new substantial engine fea- 
ture that was to be added and it was a 
complicated piece of work. We were 
particularly nervous about this tech- 
nology for a couple of reasons. First, it 
is usually much harder to make this 
kind of pervasive change to an existing 
piece of software than it is to build it 
in from scratch. Second, Looking Glass 
had no track record in shipping multi- 
player technology and we were not 
confident that the development was 
fully understood. 

Irrational did not want to introduce 
multiplayer support into SYSTEM SHOCK 
2 because we considered it a tangential 
feature that did not contribute to our 
core strengths. However, marketing 
concerns dictated it, so ultimately we 
acquiesced. Our lack of enthusiasm for 
this feature contributed to its develop- 
mental problems because we failed to 
monitor its progress adequately or raise 
concerns when that progress fell 
behind schedule. 

Because this was the first multiplay- 
er product developed by Irrational or 
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Looking Glass, we did not properly 
estimate the time required for the 
multiplayer testing. We did not 
devote adequate quality assurance 
resources to this feature. Too much 
time was spent testing the multiplayer 
features over the LAN and not enough 
over the more demanding modem 
connections. 

Given the difficulties posed by the 
multiplayer technologies, the engine 
developers working on the task made 
great efforts, and their early results 
were promising. However, the early 
departure of one of the programmers, 
and the fact that he was not replaced, 
ultimately doomed any possibility of 
shipping the multiplayer technology 
with the initial SKU. Reluctantly, we 
opted for a patch that would be avail- 
able at the same time as the single- 
player box reached shelves. Our coop- 
erative multiplayer game will 
undoubtedly be fun and will probably 
be enjoyed immensely by a relatively 
small number of our customers. 
However, we wonder whether our fail- 
ure to deliver a promised feature in the 
box will ultimately hurt us more than 
the absence of that feature from the 
start would have. 

% RUNNING A COMPANY WHILE BUILDING 
@ aGame. As the principals of the 
company, Ken, Rob and I didn’t really 
understand what it took to run a busi- 
ness and simultaneously work in that 
business. None of the Irrational 
founders started the company to be 
businessmen, and we have always 
believed that the ultimate health of the 
company depended on us all staying 
involved in the development process, 
which is, after all, what each of us 
enjoys and wants to do. Unfortunately, 
as anyone who has run a business 
knows, there is a lot more to starting 
and maintaining a company than sit- 
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ting around at board meetings smoking 
cigars. From the mundane matters of 
making payroll, organizing taxes and 
expense reports to business negotia- 
tions and contract disputes, there is 
substantial overhead involved in run- 
ning even a small company such as 
Irrational. In our naiveté, we did not 
factor these tasks into our schedules 
and the result was that they mostly 
became extra tasks that kept us in the 
office late at night and on weekends. 

As a result of our misjudgment, we 
just had to work harder. Rather than 
enduring a crunch period of a few 
months, the entire last year of the 
project was our crunch time, as we 
struggled desperately to fulfill our jobs 
as programmers, designers, and man- 
agers as well as keep the money flow- 
ing in (and out) of the company. Our 
tasks were complicated further by the 
need to reincorporate the company 
from an S-corporation to an LLC dur- 
ing the final two months of the pro- 
ject (a legal maneuver designed to 
allow me, an Australian national, to 
be allocated company stock). 

As well as destroying our personal 
lives, our failure to judge the magni- 
tude of our task meant that we had to 
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devote less time than we desired to 
every aspect of our work. My program- 
ming time was severely curtailed and | 
was able to spend far less time on 
SYSTEM SHOCK 2’s AI than I wished. 
Simultaneously, I was unable to pro- 
vide the level of direct management 
that I wanted, and I was forced to post- 
pone company financial work until the 
end of the project or hurry it through. 
The results were less than optimal all 
around. 

Ultimately, SYSTEM SHOCK 2 turned 
out better than I ever hoped it would. 
The final vindication for me was sitting 
in my office and playing the game in 
the final couple of weeks of the project, 
while waiting for EA to approve our 
final build. Despite the lack of sleep, 
the near-complete breakdown of my 
nervous system and the 18 months of 
time I spent working on the project, it 
was Still fun to play. I like to think that 
we have managed to capture the feel of 
the original game by putting more 
game play into what initially looks like 
a fairly straightforward first-person 
shooter. It’s been a great first project 
for Irrational Games and we look for- 
ward to doing even better the next 
time around. & 
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games for the next millennium. 


Games For The Next Millennium 
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Rick Goodman: Recipient of the 1998 Computer 


Game Developer Conference’s 


+ & 
* @& 
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We're creating the 
next-generation 
Internet-based 
learning system. 
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to build deeply — 


engaging 
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help us understand - 
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Auran |s a computer games and software development 
company, based in Brisbane, Australia. We are 
producing a Game Authoring System known as 
3.A.G.E. and a series of games projects. Auran is 
best known as the developer of Dark Reign; the RTS 
hit of S7. We are seeking a number of highly qualified 
technical and creative people: 


senior Systems Analyst 

systems Analyst 

senior Programmer 

Game Designer 

Manual Writer 

3D Artists 

3D Animators 

Quality Assurance Manager 
Recording Studio Engineer/ Manager 


Please refer to Auran’s Web site for details: 
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to a groundbreaking new enterprise? 


You are: a talented designer of interactive 
experiences, with the record to prove it. 
You have the ability to create deeply 
compelling worlds, composed of stunning 

visual environments augmented with 
appropriately engaging auditory support. 

You can demonstrate your ideas with storyboards or 

electronic prototypes, and work creatively ina team to 

bring your vision to life yet respecting the contributions 

and constraints from the expertise of others. 


We are: the creative technology arm 
of a parent organization dedicated to 
lifelong learning. We're located in 
Emeryville, CA, just across the bay from 
San Francisco. We are privately owned 
and well-funded, and our board is a who's who in the 
technology and financial world. We are strategic, with 
strengths in network and interactive technologies, as 
well as understanding people, learning, and fun. We 
offer a competitive salary, an energized workplace with 
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After Effects, Alias, Animo, 
Director, Digital Studio, 
Houdini, Illustrator, Flint, 
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continued from page 64. 


got to build it. 

How? As recently as 1991, a typical 
computer game cost around $250,000 
to develop. Graphics and sound have 
improved a lot since then, but comput- 
er games haven’t gotten any better as 
games. You don’t need $1.5 million in 
development funding to develop a first- 

rate game; you can do it on a $250,000 
to $400,000 budget. You just can’t get 
shelf space for a low-budget game. 

But at that level, you don’t need 
100,000 unit sales. You can make 
money if you can get rid of 20,000 
copies. And how tough can that be? 
Hell, 12 years ago, I sold more than 
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AK Peters Ltd. 
Alias|Wavefront 

Apple Computer 

Atomic Games 

Auran Developments Ltd. 
Black Ops Entertainment Inc. 
Busybox.com Inc 
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Conitec Datensysteme GmbH 
Credo Interactive 

Digimation 

Evans & Sutherland 

Global Majic Software 
Immersion Corporation 

Intel 
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20,000 copies of a wonky little paper 
game called Paranoia through a wonky 
little distribution chain cobbled 
together out of specialty hobby game 
stores and comic shops. I doubt I had 
500 points of sale in North America. 

It can be done. 

Some people are trying; Firaxis will 
be selling SID MEIER’S ANTIETAM! direct 
to consumers — no retail distribution. 
Michael Berlyn is bravely struggling to 
keep the text adventure alive through 
direct sales (see 

), 

But we need more. We need a com- 

pany committed to publishing truly 


NAME 


original, offbeat, cool product and 
building the channel for its distribu- 
tion — instead of shoveling the same 
old crap to the same old stores. 

Gaming needs an indie label — for 
the sake of its own health, to act as 
basic R&D for the entire field, and to 
find new gaming styles that can 
attract a large audience. Because 
development costs continue to spiral 
upward faster than unit sales and we 
have to find a way to break that iron 
cycle. But most importantly, because 
I’m tired of the same old same old and 
want to play something really cool 
and new. Don’t you? ® 


23 Knowledge Universe Interactive 61 
21 LIPSInc 14 
17A Metrowerks Inc. C3 
61 Multigen 6 
61 Newtek 33 
61 Numerical Design Ltd. 42 
(2.4 North by Northwest 2 
62 Okino Computer Graphics 23 
63 RAD Game Tools Inc. C4 
39 Resounding Technology 58 
26 Savannah College of Art and Design 62 
37 Sound Werx 59 
18 Spatial Technology 29 
35 Stainless Steel Studios 60 
5 Viewpoint 9 


Authoring System 
for 3-D Realtime Applications 


@ 3-D applications without programming skills! 

@ Contains World Editor and the ACKNEX 3-D engine 

@ Free 3-D template game with 150+ textures included 

@ 3-D polygonal landscapes with slopes, bridges, buildings 
@ Player can walk, drive, fly, climb, swim, dive... 

@ User-defined panels, overlays, cockpits, and scrolling text 
@ Create your own objects, actors, walls, weapons, menus 
@ Resolution 320x400 (lite) up to 800x600 (professional) 
@ 8-channel stereo sound & midi; FLIC player (professional) 
@ Imports PCX, LBM, MDL, WAV, MID and IBK files 

@ Supports both DOS and Windows 95/98 with DirectX 5° 
@ 200+ pages English manual with game tutorial 
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3D: GameStudio-Lite-.5..00000.00 $99 
3D; GameStudio. Commercial ee S$ 1:99 


(+ Polygonal Actors + 2-Player Modem/Network + CD-Audio + FLIC) 


Infos, demos, u user forum - > > http: / /www.conitec.com 


1951 4th Ave, Ste 301 = San Diego CA 92101 
Tel (619) 702-4420 wg Fax 702-4419 gs www.conitec.com 
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Why We Need an Indie Label Now 





It’s not owned by Sony or Time Warner 
or BMG. Hersh doesn’t get the kind of 
promo that major-label artists do — 
but she has more control over what 
gets released. Hersh is probably never 
going to chart — but she makes 
enough to live quite well, and reaches 
an audience of enthusiasts. 

Tonight, I’m going down to the 
Angelika with my sweetie. It’s New 
York’s primary venue for independent 
films. The movies they show are 
never going to appear at your 
local Odeon or Sony theater; 
they’ll be lucky to reach 
SOO screens in the 
States. But there are 
enough theaters 
like the Angelika 
to support a 
whole market 
for indepen- 
dent films — @& 
films that 
will never gross as 
much as a Hollywood blockbuster, but 
reach an audience of enthusiasts and 
earn enough to let many people live 
quite well. 

At times, the music and movie 
industries look dull and played out and 
repetitive. You get the same damn for- 
mulas over and over, the same artists, 
the same directors. But that never lasts, 
and for one single reason: there’s a 
venue for independent work. Indie 
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freelance game designer and writer. He has 
_ CD-ROM, board, and role-playing games, three novels, and a slew of short stories. He | 
_ writes about games for a variety of web and print publications including Salon and 

| Happy Puppy, and recently completed an analyst’s report on the future of online 


games for Goodreports.com. Visit his web site at littp://ww 


ast night, I went to see Kristin Hersh play at 
the Knitting Factory. You may not have heard 
of her, but the club was packed. Hersh releas- 


es her music on 4AD, an independent label. 


labels and indie film companies experi- 
ment, at lower budgets, with the off- 
beat and original. And sometimes, they 
hit a nerve, build an audience, and ulti- 
mately rejuvenate the field. It happens 
continually in the music business, and 
it happened in film this past summer 
with The Blair Witch 
| Project. 
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"illustration by Jackie Urbanovic 


Right now, the game industry looks 
dull and played out and repetitive. We 
get the same damn formulas over and 
over again. Yet another shooter. Yet 
another RTS game. Yet another racer. 

A title as original or offbeat as SIMCITY 
or BALANCE OF POWER or M.U.L.E. — 
hell, or FROGGER — could not get funded 
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today. Gaming needs a venue for inde- 
pendent work. 

Last year, Miller Freeman did the 
industry a service by launching the 
Independent Games Festival. It’s a place 
for “garage” developers to showcase 
product, get exposure, and maybe land 
a publisher. That’s great, but it’s not 
enough — because they’re dealing with 
the same publishers as everyone else: 
EA, Interplay, GT, and others of their 
ilk. The majors will fund the tried and 
true, another shooter or RTS or racer. 
They’ll happily exploit low-budget new- 
bies who develop something that fits 
into slots they know how to sell — but 
they’re not going to experiment with 
something new, something offbeat, 
something that will probably fail but 
just might rejuvenate the field. 

The problem? There’s no way to dis- 

tribute an independent game. Yes, with 
a little effort, you can 
land a meeting 

} with the buyer 

f, for CompUSA or 
'@ Electronics Bou- 
p tique or Software 
” Etc., but they’re 
24 not going to buy 
your game with- 
out the high-bud- 
get graphic glitz they 
expect from the majors, six 
figures in placement bucks, and a com- 
mitment to a major marketing cam- 
paign. The typical mall software outlet 
still has only 40 facings for computer 
games, and there are at least 1,500 
entertainment titles published annually. 
Anything that doesn’t fit the mold isn’t 
going to get exposure. 

Indie films work because there’s a sep- 
arate distribution channel parallel to the 
one for conventional film. Indie music 
works because there are a million record 
stores that cater to a million different 
tastes and a million small clubs where 
you can play to build an audience. 

We've got nothing similar. We've 


continued on page 63. 
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My game is DOA if | don't 
ship on time. 





solves problems. Reduce your build time by as much as 90% with our 
industrial-strength software development tools. CodeWarrior tools are easy to use and 
they support multiple platforms, so you save even more time - shorten the Learning 


curve, cut support costs, reduce porting times. CodeWarrior decreases production time 


Ong tfereases profit. No problem with that, right? 


1.800.377.5416 


Find out how CodeWarrior can help you meet your deadlines: 


www.metrowerks.com/deadlines 














Introducing Bink - the new true-color codec from the author of Smacker! 

Bink is available and revolutionizing game videos just as Smacker did four years ago! Bink'js a “better-than-MPEG-II” class 

codec. Yes, that’s right - better than DVD! It produces higher quality than MPEG IJ and is up to three times faster than other 
software decoders. Now there is finally a true-color codec good enough for game developers: 


Bink is a hybrid block-transform and wavelet codec that can encode your video. using 16 different compression techniques (wavelet, _ 
DCT, motion compensation, a variety of vector quantizers, Smacker-style, etc). With all of these techniques in one codec, Bink ° 
can handle almost any type of video. Bink also includes a psycho-acoustic based audio codec that is capable of 8 to | perceptibly 
lossless compression, so your audio will sound as good as your video looks. 


Bink is available now for Windows 95/NT (DOS and MacOS coming soon) and supports DirectDraw, DIBSections, DirectSound, and the Windows 
waveQOut system. Bink uses the YUV colorspace, so it can use DirectDraw overlays for hardware color conversion and smooth scaling. Bink also includes a 
bunch of hand-optimized assembly YUV to RGB colorspace blitters, so you'll be able to access Bink’s output in any RGB format you like. Bink is a high-end 
codec, and as such, it requires at least a Pentium/150 (Pentium/200 preferred). Bink really doesn’t have a minimum CD requirement - 320x240 animations 
look great at 100 kps (<1x CD) and 640x480's only need 300 kps (2x CD). Bink does need a reasonable video card that is capable of pumping out all those 


true-color pixels, though. The Bink SDK is very similar to our popular Smacker SDK, so integration is easy, and upgrading from Smacker is easier still. 


Youre really going to love Bink - download the Bink Tools (or call for a demo CD) and try it on your videos today! 


New 5.5 version! Includes Internet voice chat, A3D 2 support, licensable QSound support, x87 and 3DNow hand- 
optimized MP3 playback, and much more! 
Miles 5.5 now has three amazing voice chat codecs that are designed for Internet voice chat applications. They can 
compress to 2900, 2400, or 1200 bits/second - more than 100 to 1 compression! Miles also supplies a complete 
TCP/IP client-server voice chat example that you can use to integrate chat into your game painlessly. Miles 5.5 
BP also includes full A3D 2 support - you can either pass down geometry directly or use the Miles simplified room 
‘ “model that encapsulates both A3D 2 and EAX. Miles provides an evaluation QSound 3D audio provider (licensable 
| for redistribution from QSound). Miles 5.5 also includes both x87 and 3D Now optimized versions of our MP3 
SOUND SYSTEM ~ decoder (x87 up to 10% faster, 3 Now up to 50% faster). 


Of course, Miles 5.5 still has all the great features you enjoyed in previous versions! 

Miles includes complete digital mixing with format conversion, reverb, filtering, and plug-in support (Miles even replaces the DirectSound mixer which can 
potentially double your frame rate), interactive MIDI playback with a built-in DLS software synthesizer, hard drive or CD-ROM digital streaming, red book 
CD-audio support, powerful callbacks, and more! Miles also includes a redistributable MPEG Layer-3 decoder (patent rights licensed from Thomson and 
Fraunhofer). The MP3 format provides perceptually lossless compression at 11 to 1! Your sound files will be more than ten times smaller and will sound 
exactly the same! Miles supports both on-the-fly decompression (for minimal memory use), or pre-playback decompression (for minimal CPU hit). 


Finally, Miles includes a high-level 3D sound API that supports our built-in RSX 3D epee (acquired from Intel), fast 2D simulated, DirectSound3D, 
Creative's EAX, Dolby-certified SurroundSound, licensable QSound, and Aureal’s A3D 1.0 & 2.0 (all selectable at run-time). Even better, you won't be tied 
to a particular low-level 3D API, so you can use the technology that makes your game sound best. Get 3D audio into your game in minutes! 


Smacker - the best 256-color codec on the planet! 
Smacker is still available and better than ever! Smacker is still the best codec for situations such as: 256 color games (of 
course), games targeting low-end machines (Pentium 133 and below), games that need video sprites or video transparency 
© (which is much faster in 256 colors), cell-based (cartoon-style) videos, animated 3D texture compression, and very high- 
resolution videos (800x600 or 1024x768 - only Smacker is fast enough for videos this big). 


* The Smacker SDK is available for DOS, 16-bit Windows, Windows 95/ NT, Win32s, 68K Mac, and PowerMac. Smacker 
, supports DirectDraw, DIBSections, WinG, DispDIB, SVGA VESA, and GWorlds (MacOS) for graphics output. For sound output, Smacker 
supports the Miles Sound System, DirectSound, the Windows waveOut system, and the Sound Manager (MacOS). The Smacker API is identical across 
platforms, and Smacker files can be played without conversion on each platform. 









Who’s using RAD? Everyone! Here's a partial list of our customers: 
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vss OVer 2,400 games - see our web site for title lists! } GAME. ‘TO O11 Ss 


